geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kirk Lund <kl...@apache.org>
Subject Re: Debugging intermittent dunit failures
Date Tue, 12 Dec 2017 00:16:48 GMT
Is there a reason we can't change DistributedTestCase and subclasses to use
TemporaryFolder for all artifacts?

We could also disconnectAllFromDS in @AfterClass (or even @After) to get
things a bit more separate between dunit test classes.

Running dunit tests in parallel is much more important than trying to reuse
distributed system across multiple dunit tests. The latter just isn't worth
the headache and trouble that it causes when static vars or constants or
disk artifacts pollute later tests.

On Mon, Dec 11, 2017 at 1:42 PM, Dan Smith <dsmith@pivotal.io> wrote:

> One other thing you can do is look for the below line in the logs of your
> failure. These are the tests that ran in the same JVM as your tests. This
> won't help if your tests are getting messed up by disk artifacts or port
> issues, but if it is some JVM state left by a previous test it would be in
> this list.
>
> Previously run tests: [ClientServerMiscSelectorDUnitTest,
> ClientConflationDUnitTest, ReliableMessagingDUnitTest]
>
> On Mon, Dec 11, 2017 at 1:14 PM, Jens Deppe <jensdeppe@apache.org> wrote:
>
> > I've recently debugged various distributed tests which fail as a result
> of
> > prior tests not cleaning up enough. It's somewhat painful and this is my
> > usual debug process:
> >
> >
> >    - Examine the progress.txt file to determine which tests ran before my
> >    failing test.
> >    - I pick 20-25 of these tests and create a Suite (including my failing
> >    test) - as these tests may have run in parallel, it's not clear which
> > tests
> >    would have run immediately prior to your test
> >    - Run the whole suite to see if I can get my test to fail
> >    - Bisect or manually iterate through the tests to see which one is
> >    causing the problem.
> >
> >
> > The last step is painful, so I've updated SuiteRunner to use a
> 'candidate'
> > test class and run this class after every other class in the list of
> > SuiteClasses. For example:
> >
> > @Suite.SuiteClasses(value = {
> >     org.apache.geode.cache.snapshot.SnapshotByteArrayDUnitTest.class,
> >     org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTes
> > t.class,
> >     org.apache.geode.cache.query.internal.index.
> > MultiIndexCreationDUnitTest.class,
> > })
> >  @SuiteRunner.Candidate(org.apache.geode.management.
> > internal.configuration.ClusterConfigDistributionDUnitTest.class)
> > @RunWith(SuiteRunner.class)
> > public class DebugSuite {
> > }
> >
> >
> > The Candidate is optional, but this would run the following tests:
> >
> > - SnapshotByteArrayDUnitTest
> > - *ClusterConfigDistributionDUnitTest*
> > - QueryDataInconsistencyDUnitTest
> > - *ClusterConfigDistributionDUnitTest*
> > - MultiIndexCreationDUnitTest
> > - *ClusterConfigDistributionDUnitTest*
> >
> > --Jens
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message