I don't think we are trying to reuse the distributed system - it gets
disconnected after each test. See JUnit4DistributedTestCase.tearDownVM.
Are the new junit rules also cleaning things up?
-Dan
On Mon, Dec 11, 2017 at 4:16 PM, Kirk Lund <kl...@apache.org> wrote:
> 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 <dsm...@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 <jensde...@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
> > >
> >
>
