Geode tests completed in pipeline with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/23

Re: Debugging intermittent dunit failures

[Jinmei Liao]

It doesn't call as much static methods as JUnit4DistributedTestCase.tearDownVM,
see MemberStarterRule.after().

On Mon, Dec 11, 2017 at 4:36 PM, Dan Smith  wrote:

> 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  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  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 
> > 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
> > > >
> > >
> >
>



-- 
Cheers

Jinmei

Re: Debugging intermittent dunit failures

[Dan Smith]

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  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  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 
> 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
> > >
> >
>

Re: Debugging intermittent dunit failures

[Kirk Lund]

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  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  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
> >
>

Re: Default branch for geode should be 'develop'

[Jens Deppe]

Thanks - I think that should do it :) Jira submitted.

On Mon, Dec 11, 2017 at 3:34 PM, Dave Barnes  wrote:

> +1
>
> On Mon, Dec 11, 2017 at 3:14 PM, Nabarun Nag  wrote:
>
> > +1
> >
> > On Mon, Dec 11, 2017 at 3:10 PM Bruce Schuchardt  >
> > wrote:
> >
> > > +1
> > >
> > >
> > > On 12/11/17 1:40 PM, Jens Deppe wrote:
> > > > Currently, github has the default branch for apache/geode set to
> > > 'master'.
> > > > (which is why you need to point the relevant branch to 'develop' for
> > > every
> > > > new PR).
> > > >
> > > > Do we agree that this should be set to 'develop'?
> > > >
> > > > (I've messaged with some of the Infra folks and nothing appears to
> have
> > > > changed recently so this is a bit weird).
> > > >
> > > > I'll create a Jira once there is agreement.
> > > >
> > > > --Jens
> > > >
> > >
> > >
> >
>

Re: Default branch for geode should be 'develop'

[Dave Barnes]

+1

On Mon, Dec 11, 2017 at 3:14 PM, Nabarun Nag  wrote:

> +1
>
> On Mon, Dec 11, 2017 at 3:10 PM Bruce Schuchardt 
> wrote:
>
> > +1
> >
> >
> > On 12/11/17 1:40 PM, Jens Deppe wrote:
> > > Currently, github has the default branch for apache/geode set to
> > 'master'.
> > > (which is why you need to point the relevant branch to 'develop' for
> > every
> > > new PR).
> > >
> > > Do we agree that this should be set to 'develop'?
> > >
> > > (I've messaged with some of the Infra folks and nothing appears to have
> > > changed recently so this is a bit weird).
> > >
> > > I'll create a Jira once there is agreement.
> > >
> > > --Jens
> > >
> >
> >
>

Jenkins build is back to normal : Geode-nightly-flaky #189

[Apache Jenkins Server]

See 

Geode tests completed in pipeline with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/32

Geode tests completed in pipeline with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/31

Re: Default branch for geode should be 'develop'

[Nabarun Nag]

+1

On Mon, Dec 11, 2017 at 3:10 PM Bruce Schuchardt 
wrote:

> +1
>
>
> On 12/11/17 1:40 PM, Jens Deppe wrote:
> > Currently, github has the default branch for apache/geode set to
> 'master'.
> > (which is why you need to point the relevant branch to 'develop' for
> every
> > new PR).
> >
> > Do we agree that this should be set to 'develop'?
> >
> > (I've messaged with some of the Infra folks and nothing appears to have
> > changed recently so this is a bit weird).
> >
> > I'll create a Jira once there is agreement.
> >
> > --Jens
> >
>
>

Re: Default branch for geode should be 'develop'

[Bruce Schuchardt]

+1


On 12/11/17 1:40 PM, Jens Deppe wrote:

Currently, github has the default branch for apache/geode set to 'master'.
(which is why you need to point the relevant branch to 'develop' for every
new PR).

Do we agree that this should be set to 'develop'?

(I've messaged with some of the Infra folks and nothing appears to have
changed recently so this is a bit weird).

I'll create a Jira once there is agreement.

--Jens

Geode tests completed in pipeline with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/29

Re: Default branch for geode should be 'develop'

[Mark Bretl]

+1

On Mon, Dec 11, 2017 at 2:07 PM, Dan Smith  wrote:

> +1
>
> -Dan
>
> On Mon, Dec 11, 2017 at 1:40 PM, Jens Deppe  wrote:
>
> > Currently, github has the default branch for apache/geode set to
> 'master'.
> > (which is why you need to point the relevant branch to 'develop' for
> every
> > new PR).
> >
> > Do we agree that this should be set to 'develop'?
> >
> > (I've messaged with some of the Infra folks and nothing appears to have
> > changed recently so this is a bit weird).
> >
> > I'll create a Jira once there is agreement.
> >
> > --Jens
> >
>

Geode tests completed in pipeline with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/21

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #763 was SUCCESSFUL (with 2264 tests)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #763 was successful.
---
Scheduled
2266 tests in total.

https://build.spring.io/browse/SGF-NAG-763/





--
This message is automatically generated by Atlassian Bamboo

Re: Default branch for geode should be 'develop'

[Dan Smith]

+1

-Dan

On Mon, Dec 11, 2017 at 1:40 PM, Jens Deppe  wrote:

> Currently, github has the default branch for apache/geode set to 'master'.
> (which is why you need to point the relevant branch to 'develop' for every
> new PR).
>
> Do we agree that this should be set to 'develop'?
>
> (I've messaged with some of the Infra folks and nothing appears to have
> changed recently so this is a bit weird).
>
> I'll create a Jira once there is agreement.
>
> --Jens
>

Re: Default branch for geode should be 'develop'

[Jinmei Liao]

+1

On Mon, Dec 11, 2017 at 2:30 PM, Patrick Rhomberg 
wrote:

> +1 for smoother workflow.
>
> On Mon, Dec 11, 2017 at 2:14 PM, Darrel Schneider 
> wrote:
>
> > +1
> >
> > On Mon, Dec 11, 2017 at 1:40 PM, Jens Deppe 
> wrote:
> >
> > > Currently, github has the default branch for apache/geode set to
> > 'master'.
> > > (which is why you need to point the relevant branch to 'develop' for
> > every
> > > new PR).
> > >
> > > Do we agree that this should be set to 'develop'?
> > >
> > > (I've messaged with some of the Infra folks and nothing appears to have
> > > changed recently so this is a bit weird).
> > >
> > > I'll create a Jira once there is agreement.
> > >
> > > --Jens
> > >
> >
>



-- 
Cheers

Jinmei

Re: Default branch for geode should be 'develop'

[Patrick Rhomberg]

+1 for smoother workflow.

On Mon, Dec 11, 2017 at 2:14 PM, Darrel Schneider 
wrote:

> +1
>
> On Mon, Dec 11, 2017 at 1:40 PM, Jens Deppe  wrote:
>
> > Currently, github has the default branch for apache/geode set to
> 'master'.
> > (which is why you need to point the relevant branch to 'develop' for
> every
> > new PR).
> >
> > Do we agree that this should be set to 'develop'?
> >
> > (I've messaged with some of the Infra folks and nothing appears to have
> > changed recently so this is a bit weird).
> >
> > I'll create a Jira once there is agreement.
> >
> > --Jens
> >
>

Geode tests completed in pipeline with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/27

Re: Debugging intermittent dunit failures

[Dan Smith]

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  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
>

Geode tests completed in pipeline with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/30

Re: Default branch for geode should be 'develop'

[Darrel Schneider]

+1

On Mon, Dec 11, 2017 at 1:40 PM, Jens Deppe  wrote:

> Currently, github has the default branch for apache/geode set to 'master'.
> (which is why you need to point the relevant branch to 'develop' for every
> new PR).
>
> Do we agree that this should be set to 'develop'?
>
> (I've messaged with some of the Infra folks and nothing appears to have
> changed recently so this is a bit weird).
>
> I'll create a Jira once there is agreement.
>
> --Jens
>

Default branch for geode should be 'develop'

[Jens Deppe]

Currently, github has the default branch for apache/geode set to 'master'.
(which is why you need to point the relevant branch to 'develop' for every
new PR).

Do we agree that this should be set to 'develop'?

(I've messaged with some of the Infra folks and nothing appears to have
changed recently so this is a bit weird).

I'll create a Jira once there is agreement.

--Jens

Build failed in Jenkins: Geode-nightly #1040

[Apache Jenkins Server]

See 

--
[...truncated 210.28 KB...]

659 tests completed, 1 failed, 19 skipped
:geode-cq:distributedTest FAILED
:geode-cq:integrationTest
:geode-json:assemble
:geode-json:compileTestJava NO-SOURCE
:geode-json:processTestResources
:geode-json:testClasses
:geode-json:checkMissedTests NO-SOURCE
:geode-json:spotlessJavaCheck
:geode-json:spotlessCheck
:geode-json:test NO-SOURCE
:geode-json:check
:geode-json:build
:geode-json:distributedTest NO-SOURCE
:geode-json:integrationTest NO-SOURCE
:geode-junit:javadoc
:geode-junit:javadocJar
:geode-junit:sourcesJar
:geode-junit:signArchives SKIPPED
:geode-junit:assemble
:geode-junit:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: 

 uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-junit:processTestResources
:geode-junit:testClasses
:geode-junit:checkMissedTests
:geode-junit:spotlessJavaCheck
:geode-junit:spotlessCheck
:geode-junit:test
:geode-junit:check
:geode-junit:build
:geode-junit:distributedTest
:geode-junit:integrationTest
:geode-lucene:assemble
:geode-lucene:compileTestJavaNote: Some input files use or override a 
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

:geode-old-client-support:processTestResources NO-SOURCE
:geode-old-client-support:testClasses
:geode-old-client-support:checkMissedTests
:geode-old-client-support:spotlessJavaCheck
:geode-old-client-support:spotlessCheck
:geode-old-client-support:test
:geode-old-client-support:check
:geode-old-client-support:build
:geode-old-client-support:distributedTest
:geode-old-client-support:integrationTest
:geode-old-versions:distributedTest NO-SOURCE
:geode-old-versions:integrationTest NO-SOURCE
:geode-protobuf:assemble
:geode-protobuf:compileTestJavaNote: Some input files use or override a 
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-protobuf:processTestResources
:geode-protobuf:testClasses
:geode-protobuf:checkMissedTests
:geode-protobuf:spotlessJavaCheck
:geode-protobuf:spotlessCheck
:geode-protobuf:test
:geode-protobuf:check
:geode-protobuf:build
:geode-protobuf:distributedTest
:geode-protobuf:integrationTest
:geode-protobuf-messages:assemble
:geode-protobuf-messages:extractIncludeTestProto
:geode-protobuf-messages:extractTestProto UP-TO-DATE
:geode-protobuf-messages:generateTestProto NO-SOURCE
:geode-protobuf-messages:compileTestJava NO-SOURCE
:geode-protobuf-messages:processTestResources NO-SOURCE
:geode-protobuf-messages:testClasses UP-TO-DATE
:geode-protobuf-messages:checkMissedTests NO-SOURCE
:geode-protobuf-messages:spotlessJavaCheck
:geode-protobuf-messages:spotlessCheck
:geode-protobuf-messages:test NO-SOURCE
:geode-protobuf-messages:check
:geode-protobuf-messages:build
:geode-protobuf-messages:distributedTest NO-SOURCE
:geode-protobuf-messages:integrationTest NO-SOURCE
:geode-pulse:assemble
:geode-pulse:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: 

 uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck
:geode-pulse:spotlessCheck
:geode-pulse:test
:geode-pulse:check
:geode-pulse:build
:geode-pulse:distributedTest
:geode-pulse:integrationTest
:geode-rebalancer:assemble
:geode-rebalancer:compileTestJava
:geode-rebalancer:processTestResources NO-SOURCE
:geode-rebalancer:testClasses
:geode-rebalancer:checkMissedTests
:geode-rebalancer:spotlessJavaCheck
:geode-rebalancer:spotlessCheck

Debugging intermittent dunit failures

[Jens Deppe]

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.QueryDataInconsistencyDUnitTest.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

Geode tests completed in pipeline with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/26