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

Build failed in Jenkins: Geode-nightly #1042

[Apache Jenkins Server]

See 


Changes:

[nabarunnag] GEODE-3929: GFSH create lucene index command allowed on existing

[github] GEODE-4076: throw AuthenticationRequiredException instead of

[github] GEODE-4078: Display full path when locator view log cannot be opened

[github] GEODE-3869: Fix early eviction. (#1152)

[github] GEODE-4081: update cluster config after destroy gateway sender (#1140)

--
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on ubuntu-eu3 (ubuntu xenial) in workspace 

Cloning the remote Git repository
Cloning repository https://github.com/apache/geode.git
 > git init  # timeout=10
Fetching upstream changes from https://github.com/apache/geode.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/apache/geode.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url https://github.com/apache/geode.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url https://github.com/apache/geode.git # timeout=10
Fetching upstream changes from https://github.com/apache/geode.git
 > git fetch --tags --progress https://github.com/apache/geode.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/develop^{commit} # timeout=10
Checking out Revision db30e3f4fa6721163720c25ce8e82c2162da7847 
(refs/remotes/origin/develop)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f db30e3f4fa6721163720c25ce8e82c2162da7847
 > git branch -a -v --no-abbrev # timeout=10
 > git checkout -b develop db30e3f4fa6721163720c25ce8e82c2162da7847
Commit message: "GEODE-4081: update cluster config after destroy gateway sender 
(#1140)"
 > git rev-list 08944b0881e59332cf614b6becd3d5aaa3e13ac8 # timeout=10
[Geode-nightly] $ /bin/bash -xe /tmp/jenkins1099068935677469958.sh
+ git status
On branch develop
nothing to commit, working directory clean
[Geode-nightly] $ /bin/bash -xe /tmp/jenkins8178123457838413278.sh
+ docker pull apachegeode/geode-build
Using default tag: latest
Warning: failed to get default registry endpoint from daemon (Cannot connect to 
the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon 
running?). Using system default: https://index.docker.io/v1/
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the 
docker daemon running?
Build step 'Execute shell' marked build as failure
Archiving artifacts
Recording test results
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?
Not sending mail to unregistered user git...@nakomis.com
Not sending mail to unregistered user dsm...@pivotal.io
Not sending mail to unregistered user jde...@gopivotal.com
Not sending mail to unregistered user metat...@users.noreply.github.com
Not sending mail to unregistered user jhuynh@Jason-Huynh-MacBook-Pro.local
Not sending mail to unregistered user jil...@pivotal.io
Not sending mail to unregistered user nabarun...@users.noreply.github.com

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

[Spring CI]

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

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





--
This message is automatically generated by Atlassian Bamboo

Re: Debugging intermittent dunit failures

[Alexander Murmann]

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

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

Re: Debugging intermittent dunit failures

[Kirk Lund]

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

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