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

Build failed in Jenkins: Geode-nightly-flaky #192

[Apache Jenkins Server]

See 


Changes:

[dschneider] GEODE-4091: add ThreadFactory for evictor

[github] GEODE-4083: fix infinite loop caused by thread race changing version

[dschneider] GEODE-4099: change warning to debug

[github] GEODE-3799: Move backups towards a pluggable architecture (#1109)

[github] GEODE-2296: Internal message SIZE should not have authorization checks

[github] GEODE-3539: add tests for ExportStackTraceCommand (#1162)

[github] GEODE-4103: Set forkEvery=1 for distributedTest (#1170)

[github] GEODE-3923 Document the 2 new properties serializable-object-filter

[gosullivan] GEODE-4084 rename handshake.proto (#1155)

[github] GEODE-4047 User Guide: Update Lucene docs to include nested objects

[dbarnes] GEODE-4047 User Guide: Update Lucene docs to include nested objects,

[nabarunnag] GEODE-4079: Deprecated Hash Index

--
[...truncated 129.39 KB...]
:geode-client-protocol:javadoc
:geode-client-protocol:javadocJar
:geode-client-protocol:sourcesJar
:geode-client-protocol:signArchives SKIPPED
:geode-common:javadocJar
:geode-common:sourcesJar
:geode-common:signArchives SKIPPED
:geode-core:javadocJar
:geode-core:raJar
:geode-core:jcaJar
:geode-core:sourcesJar
:geode-core:signArchives SKIPPED
:geode-core:webJar
:geode-cq:jar
:geode-cq:javadoc
:geode-cq:javadocJar
:geode-cq:sourcesJar
:geode-cq:signArchives SKIPPED
:geode-json:javadocJar
:geode-json:sourcesJar
:geode-json:signArchives SKIPPED
:geode-lucene:jar
:geode-lucene:javadoc
:geode-lucene:javadocJar
:geode-lucene:sourcesJar
:geode-lucene:signArchives SKIPPED
:geode-old-client-support:jar
:geode-old-client-support:javadoc
:geode-old-client-support:javadocJar
:geode-old-client-support:sourcesJar
:geode-old-client-support:signArchives SKIPPED
:geode-protobuf:jar
:geode-protobuf-messages:javadoc
:geode-protobuf:javadoc
:geode-protobuf:javadocJar
:geode-protobuf:sourcesJar
:geode-protobuf:signArchives SKIPPED
:geode-protobuf-messages:javadocJar
:geode-protobuf-messages:sourcesJar
:geode-protobuf-messages:signArchives SKIPPED
:geode-protobuf-messages:zip
:geode-pulse:javadoc
:geode-pulse:javadocJar
:geode-pulse:sourcesJar
:geode-pulse:war
:geode-pulse:signArchives SKIPPED
:geode-rebalancer:jar
:geode-rebalancer:javadoc
:geode-rebalancer:javadocJar
:geode-rebalancer:sourcesJar
:geode-rebalancer:signArchives SKIPPED
:geode-wan:jar
:geode-wan:javadoc
:geode-wan:javadocJar
:geode-wan:sourcesJar
:geode-wan:signArchives SKIPPED
:geode-web:javadoc NO-SOURCE
:geode-web:javadocJar
:geode-web:sourcesJar
:geode-web:war
:geode-web:signArchives SKIPPED
:geode-web-api:javadoc
:geode-web-api:javadocJar
:geode-web-api:sourcesJar
:geode-web-api:war
:geode-web-api:signArchives SKIPPED
:geode-assembly:installDist
:geode-pulse:jar
:geode-assembly:compileTestJava
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core-uberjar/1.6.3/cargo-core-uberjar-1.6.3.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core/1.6.3/cargo-core-1.6.3.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/codehaus-cargo/1.6.3/codehaus-cargo-1.6.3.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core-uberjar/1.6.3/cargo-core-uberjar-1.6.3.jar
Note: 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-assembly:processTestResources
:geode-assembly:testClasses
:geode-assembly:flakyTest

org.apache.geode.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest
 > testVersionTitleForStartServerAndLocator FAILED
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.geode.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.readPid(LauncherLifecycleCommandsDUnitTest.java:195)
at 
org.apache.geode.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.waitForGemFireProcessToStop(LauncherLifecycleCommandsDUnitTest.java:260)
at 
org.apache.geode.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.stopServer(LauncherLifecycleCommandsDUnitTest.java:237)
at 
org.apache.geode.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.testVersionTitleForStartServerAndLocator(LauncherLifecycleCommandsDUnitTest.java:450)

16 tests completed, 1 failed
:geode-assembly:flakyTest FAILED
:geode-benchmarks:compileTestJava NO-SOURCE
:geode-benchmarks:processTestResources NO-SOURCE
:geode-benchmarks:testClasses UP-TO-DATE
:geode-benchmarks:flakyTest NO-SOURCE
:geode-client-protocol:compileTestJava NO-SOURCE
:geode-client-protocol:processTestResources NO-SOURCE
:geode-client-protocol:testClasses UP-TO-DATE

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

[Spring CI]

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

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





--
This message is automatically generated by Atlassian Bamboo

Build failed in Jenkins: Geode-nightly #1044

[Apache Jenkins Server]

See 


Changes:

[dschneider] GEODE-4091: add ThreadFactory for evictor

[github] GEODE-4083: fix infinite loop caused by thread race changing version

[dschneider] GEODE-4099: change warning to debug

[github] GEODE-3799: Move backups towards a pluggable architecture (#1109)

--
[...truncated 771.76 KB...]
: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
:geode-rebalancer:test
:geode-rebalancer:check
:geode-rebalancer:build
:geode-rebalancer:distributedTest
:geode-rebalancer:integrationTest
:geode-wan:assemble
:geode-wan: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-wan:processTestResources
:geode-wan:testClasses
:geode-wan:checkMissedTests
:geode-wan:spotlessJavaCheck
:geode-wan:spotlessCheck
:geode-wan:test
:geode-wan:check
:geode-wan:build
:geode-wan:distributedTest

org.apache.geode.internal.cache.wan.misc.NewWanAuthenticationDUnitTest > 
testWanAuthValidCredentials FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.wan.misc.NewWanAuthenticationDUnitTest$$Lambda$446/70160879.run
 in VM 2 running on Host asf913.gq1.ygridcore.net with 8 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
at org.apache.geode.test.dunit.VM.invoke(VM.java:363)
at org.apache.geode.test.dunit.VM.invoke(VM.java:308)
at 
org.apache.geode.internal.cache.wan.misc.NewWanAuthenticationDUnitTest.testWanAuthValidCredentials(NewWanAuthenticationDUnitTest.java:113)

Caused by:
org.apache.geode.internal.cache.wan.GatewaySenderException: Could not 
start a gateway sender ln because of exception 
org.apache.geode.security.AuthenticationFailedException: DummyAuthenticator: 
Invalid user name [invalid1], password supplied., caused by 
org.apache.geode.security.AuthenticationFailedException: DummyAuthenticator: 
Invalid user name [invalid1], password supplied.
at 
org.apache.geode.internal.cache.wan.AbstractGatewaySender.waitForRunningStatus(AbstractGatewaySender.java:752)
at 
org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderImpl.start(SerialGatewaySenderImpl.java:90)
at 
org.apache.geode.internal.cache.wan.WANTestBase.startSender(WANTestBase.java:1119)
at 
org.apache.geode.internal.cache.wan.misc.NewWanAuthenticationDUnitTest.lambda$testWanAuthValidCredentials$bb17a952$4(NewWanAuthenticationDUnitTest.java:113)

Caused by:
org.apache.geode.security.AuthenticationFailedException: 
DummyAuthenticator: Invalid user name [invalid1], password supplied.

org.apache.geode.internal.cache.wan.misc.NewWanAuthenticationDUnitTest > 
testWanAuthValidCredentialsWithServer FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.wan.misc.NewWanAuthenticationDUnitTest$$Lambda$471/410285177.run
 in VM 2 running on Host asf913.gq1.ygridcore.net with 8 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
at org.apache.geode.test.dunit.VM.invoke(VM.java:363)
at org.apache.geode.test.dunit.VM.invoke(VM.java:308)
at 

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

Re: Debugging intermittent dunit failures

[Kirk Lund]

This is even better than I hoped for.

+1 to make the change. I already approved the PR.

On Fri, Dec 15, 2017 at 7:50 AM, Jens Deppe  wrote:

> Using forkEvery=1, my distributedTest run took 3h5m which is maybe 10
> minutes slower than the random sampling I did of other tests and
> distributedTestCore took 2h35m which is on par with others.
>
> I'd say that it's worth switching to forkEvery=1 as it will most likely
> provide more consistency for test results.
>
> --Jens
>
> On Thu, Dec 14, 2017 at 4:29 PM, Patrick Rhomberg 
> wrote:
>
> > Are the AcceptanceTests currently set to fork after every one?  It might
> be
> > apples to oranges, but we could try to look at the cost difference there.
> >
> > On Thu, Dec 14, 2017 at 4:24 PM, Kirk Lund  wrote:
> >
> > > Thanks Jens! Let us know if you end up running dunit in parallel with
> > > forkevery 1 or if it's completely serial (one at a time). I think
> > parallel
> > > with docker with forkevery 1 is going to give us the best results but
> I'm
> > > sure you already know that since you're the docker king.
> > >
> > > This change would eliminate memory pollution. Any test pollution
> > remaining
> > > after this should be caused by dunit writing to non-TemporaryFolder
> > > directories such as current working directory or user's home directory.
> > >
> > > On Thu, Dec 14, 2017 at 4:08 PM, Jens Deppe  wrote:
> > >
> > > > I'll do that.
> > > >
> > > > On Thu, Dec 14, 2017 at 2:02 PM, Kirk Lund  wrote:
> > > >
> > > > > Someone needs to try it out. If there are any build-engineer types
> > > > working
> > > > > on geode, then my suggestion is for them to try this change and
> > report
> > > > the
> > > > > timing difference.
> > > > >
> > > > > On Tue, Dec 12, 2017 at 2:22 PM, Alexander Murmann <
> > > amurm...@pivotal.io>
> > > > > wrote:
> > > > >
> > > > > > Do we have a rough idea how forking every time would impact how
> > long
> > > > > tests
> > > > > > run?
> > > > > >
> > > > > > On Tue, Dec 12, 2017 at 1:39 PM, Kirk Lund 
> > wrote:
> > > > > >
> > > > > > > We should just change to fork every 1 instead of 30. Wasting
> time
> > > > > trying
> > > > > > to
> > > > > > > debug statics is well... it's a waste of time. We should be
> > focused
> > > > on
> > > > > > > other things.
> > > > > > >
> > > > > > > On Mon, Dec 11, 2017 at 9:05 PM, Jinmei Liao <
> jil...@pivotal.io>
> > > > > wrote:
> > > > > > >
> > > > > > > > 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 <
> dsm...@pivotal.io>
> > > > > 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 <
> 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.
> > > > > > > > > > >
> > > > > > > > > > > 

Fwd: [jira] [Commented] (GEODE-4061) Adding coordinator in list member command output

[dinesh 1004]

Any one vl merge this pull request?

Thanks
Dinesh
-- Forwarded message --
From: "ASF GitHub Bot (JIRA)" 
Date: 14-Dec-2017 9:45 pm
Subject: [jira] [Commented] (GEODE-4061) Adding coordinator in list member
command output
To: 
Cc:


> [ https://issues.apache.org/jira/browse/GEODE-4061?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=16291101#comment-16291101 ]
>
> ASF GitHub Bot commented on GEODE-4061:
> ---
>
> dineshpune2006 commented on issue #1138: Feature/GEODE-4061 : Adding
> coordinator in list member command output
> URL: https://github.com/apache/geode/pull/1138#issuecomment-351757529
>
>
>when this pull request is going to be merge
>
> 
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on GitHub and use the
> URL above to go to the specific comment.
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
> > Adding coordinator in list member command output
> > 
> >
> > Key: GEODE-4061
> > URL: https://issues.apache.org/jira/browse/GEODE-4061
> > Project: Geode
> >  Issue Type: Bug
> >  Components: messaging
> >Reporter: dinesh ak
> >
> > no way to find out the coordinator apart from log messages.
> > i have added coordinator in list member command output.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.14#64029)
>

Re: how to get a good commit comment when using gitbox to merge a pull request

[Jinmei Liao]

On the pull request web UI, I usually just use "Squash and Merge" which
will give me a chance to revise the commit messages.

On Thu, Dec 14, 2017 at 11:15 AM, Darrel Schneider 
wrote:

> I noticed that the git log message for a pull request I just merged was
> lacking what I expected it to pick up from the single revision in the pull
> request. It ended up with a message like this:
>
> Merge pull request #1165 from dschneider-pivotal/feature/GEODE-4091
>
>
>
> GEODE-4091: add ThreadFactory for evictor
>
>
>
> The threads created to do background eviction scanning
>
> will now be named "LRUListWithAsyncSortingThreadNNN".
>
> The will now be daemon threads.
>
> They now have an unhandled exception handler.
>
> Their group is named "LRUListWithAsyncSorting Threads".
>
>
> I wanted it to look like this:
>
> GEODE-4091: add ThreadFactory for evictor
>
>
>
> The threads created to do background eviction scanning
>
> will now be named "LRUListWithAsyncSortingThreadNNN".
>
> The will now be daemon threads.
>
> They now have an unhandled exception handler.
>
> Their group is named "LRUListWithAsyncSorting Threads".
>
> I added the last five lines to it myself because I saw they were missing.
> Did my adding those mess this up?
> Am I correct that we don't want that first line ("Merge pull request
> #...")?
>
> Thanks for any help
>



-- 
Cheers

Jinmei

Re: Debugging intermittent dunit failures

[Jens Deppe]

Using forkEvery=1, my distributedTest run took 3h5m which is maybe 10
minutes slower than the random sampling I did of other tests and
distributedTestCore took 2h35m which is on par with others.

I'd say that it's worth switching to forkEvery=1 as it will most likely
provide more consistency for test results.

--Jens

On Thu, Dec 14, 2017 at 4:29 PM, Patrick Rhomberg 
wrote:

> Are the AcceptanceTests currently set to fork after every one?  It might be
> apples to oranges, but we could try to look at the cost difference there.
>
> On Thu, Dec 14, 2017 at 4:24 PM, Kirk Lund  wrote:
>
> > Thanks Jens! Let us know if you end up running dunit in parallel with
> > forkevery 1 or if it's completely serial (one at a time). I think
> parallel
> > with docker with forkevery 1 is going to give us the best results but I'm
> > sure you already know that since you're the docker king.
> >
> > This change would eliminate memory pollution. Any test pollution
> remaining
> > after this should be caused by dunit writing to non-TemporaryFolder
> > directories such as current working directory or user's home directory.
> >
> > On Thu, Dec 14, 2017 at 4:08 PM, Jens Deppe  wrote:
> >
> > > I'll do that.
> > >
> > > On Thu, Dec 14, 2017 at 2:02 PM, Kirk Lund  wrote:
> > >
> > > > Someone needs to try it out. If there are any build-engineer types
> > > working
> > > > on geode, then my suggestion is for them to try this change and
> report
> > > the
> > > > timing difference.
> > > >
> > > > On Tue, Dec 12, 2017 at 2:22 PM, Alexander Murmann <
> > amurm...@pivotal.io>
> > > > wrote:
> > > >
> > > > > Do we have a rough idea how forking every time would impact how
> long
> > > > tests
> > > > > run?
> > > > >
> > > > > On Tue, Dec 12, 2017 at 1:39 PM, Kirk Lund 
> wrote:
> > > > >
> > > > > > We should just change to fork every 1 instead of 30. Wasting time
> > > > trying
> > > > > to
> > > > > > debug statics is well... it's a waste of time. We should be
> focused
> > > on
> > > > > > other things.
> > > > > >
> > > > > > On Mon, Dec 11, 2017 at 9:05 PM, Jinmei Liao 
> > > > wrote:
> > > > > >
> > > > > > > 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 <
> > 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: [ClientServerMiscSelectorDUnitT
> est,
> > > > > > > > > > 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
> > > > > >