Geode unit tests completed in 'develop/DistributedTest' 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/91

Build failed in Jenkins: Geode-nightly #1245

[Apache Jenkins Server]

See 


Changes:

[github] GEODE-5352: testLocalDataContextWithColocation will now wait for result

[karensmolermiller] GEODE-5350: User Guide: Specifying that 
'statistics-enabled' parameter

--
[...truncated 110.24 KB...]
> Task :geode-core:assemble
> Task :geode-core:checkMissedTests
> Task :geode-core:spotlessJava
> Task :geode-core:spotlessJavaCheck
> Task :geode-core:spotlessCheck
> Task :geode-core:test
> Task :geode-cq:assemble

> Task :geode-cq:compileTestJava
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.

> Task :geode-cq:processTestResources
> Task :geode-cq:testClasses
> Task :geode-cq:checkMissedTests
> Task :geode-cq:spotlessJava
> Task :geode-cq:spotlessJavaCheck
> Task :geode-cq:spotlessCheck
> Task :geode-cq:test
> Task :geode-experimental-driver:jar
> Task :geode-experimental-driver:javadoc
> Task :geode-experimental-driver:javadocJar
> Task :geode-experimental-driver:sourcesJar
> Task :geode-experimental-driver:signArchives SKIPPED
> Task :geode-experimental-driver:assemble

> Task :geode-experimental-driver:compileTestJava
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :geode-experimental-driver:processTestResources
> Task :geode-experimental-driver:testClasses
> Task :geode-experimental-driver:checkMissedTests
> Task :geode-experimental-driver:spotlessJava
> Task :geode-experimental-driver:spotlessJavaCheck
> Task :geode-experimental-driver:spotlessCheck
> Task :geode-experimental-driver:test
> Task :geode-json:assemble
> Task :geode-json:compileTestJava NO-SOURCE
> Task :geode-json:processTestResources
> Task :geode-json:testClasses
> Task :geode-json:checkMissedTests NO-SOURCE
> Task :geode-json:spotlessJava
> Task :geode-json:spotlessJavaCheck
> Task :geode-json:spotlessCheck
> Task :geode-json:test NO-SOURCE
> Task :geode-old-versions:javadoc NO-SOURCE
> Task :geode-junit:javadoc
> Task :geode-junit:javadocJar
> Task :geode-junit:sourcesJar
> Task :geode-junit:signArchives SKIPPED
> Task :geode-junit:assemble

> Task :geode-junit:compileTestJava
Note: 

 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.

> Task :geode-junit:processTestResources
> Task :geode-junit:testClasses
> Task :geode-junit:checkMissedTests
> Task :geode-junit:spotlessJava
> Task :geode-junit:spotlessJavaCheck
> Task :geode-junit:spotlessCheck
> Task :geode-junit:test
> Task :geode-lucene:assemble

> Task :geode-lucene:compileTestJava
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.

> Task :geode-lucene:processTestResources
> Task :geode-lucene:testClasses
> Task :geode-lucene:checkMissedTests
> Task :geode-lucene:spotlessJava
> Task :geode-lucene:spotlessJavaCheck
> Task :geode-lucene:spotlessCheck
> Task :geode-lucene:test
> Task :geode-old-client-support:assemble
> Task :geode-old-client-support:compileTestJava
> Task :geode-old-client-support:processTestResources NO-SOURCE
> Task :geode-old-client-support:testClasses
> Task :geode-old-client-support:checkMissedTests
> Task :geode-old-client-support:spotlessJava
> Task :geode-old-client-support:spotlessJavaCheck
> Task :geode-old-client-support:spotlessCheck
> Task :geode-old-client-support:test
> Task :geode-old-versions:javadocJar
> Task :geode-old-versions:sourcesJar
> Task :geode-old-versions:signArchives SKIPPED
> Task :geode-old-versions:assemble
> Task :geode-old-versions:compileTestJava NO-SOURCE
> Task :geode-old-versions:processTestResources NO-SOURCE
> Task :geode-old-versions:testClasses UP-TO-DATE
> Task :geode-old-versions:checkMissedTests NO-SOURCE
> Task :geode-old-versions:spotlessJava
> Task :geode-old-versions:spotlessJavaCheck
> Task :geode-old-versions:spotlessCheck
> Task :geode-old-versions:test NO-SOURCE
> Task :geode-protobuf:assemble
Download 
https://repo.maven.apache.org/maven2/org/powermock/powermock-api-mockito/1.7.1/powermock-api-mockito-1.7.1.pom
Download 
https://repo.maven.apache.org/maven2/org/powermock/powermock-api-mockito/1.7.1/powermock-api-mockito-1.7.1.jar

> Task :geode-protobuf:compileTestJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
N

Geode unit tests completed in 'develop/AcceptanceTest' 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/127

Geode unit tests completed in 'develop/FlakyTest' 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/115

Geode unit tests completed in 'develop/AcceptanceTest' 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/126

Geode unit tests completed in 'develop/AcceptanceTest' 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/125

Geode unit tests completed in 'develop/UITests' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

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

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #966 was successful.
---
Scheduled
2425 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Re: Rat failure

[Anthony Baker]

We could but it feels wrong :-)

The rat excludes list files that we decided are ok to include in the source 
tree.  I don’t think the gradle notification file belongs in the source tree.

Anthony


> On Jul 2, 2018, at 1:33 PM, Patrick Rhomberg  wrote:
> 
> We already have a rather extensive list of excludes in
> gradle/rat.spotless.  Another "*.rendered" could be added.
> 
> On Mon, Jul 2, 2018 at 1:05 PM, Anthony Baker  wrote:
> 
>> The GEODE_USER_DIR on jenkins is set to the workspace so it’s leaving
>> behind a notification file that causes rat to fail.
>> 
>> Anthony
>> 
>> 
>>> On Jul 2, 2018, at 9:13 AM, Kirk Lund  wrote:
>>> 
>>> Here's the rat failure on develop. I'm not sure what to make of it or
>> what
>>> changed...
>>> 
>>> Unapproved licenses:
>>> 
>>> 
>>> /home/jenkins/jenkins-slave/workspace/Geode-nightly/
>> notifications/4.8/release-features.rendered
>> 
>> 

Re: Rat failure

[Patrick Rhomberg]

We already have a rather extensive list of excludes in
gradle/rat.spotless.  Another "*.rendered" could be added.

On Mon, Jul 2, 2018 at 1:05 PM, Anthony Baker  wrote:

> The GEODE_USER_DIR on jenkins is set to the workspace so it’s leaving
> behind a notification file that causes rat to fail.
>
> Anthony
>
>
> > On Jul 2, 2018, at 9:13 AM, Kirk Lund  wrote:
> >
> > Here's the rat failure on develop. I'm not sure what to make of it or
> what
> > changed...
> >
> > Unapproved licenses:
> >
> >
> > /home/jenkins/jenkins-slave/workspace/Geode-nightly/
> notifications/4.8/release-features.rendered
>
>

Re: Requesting Pipeline Permissions

[Patrick Rhomberg]

  I was under the impression that to actually deploy a pipeline, either as
a new pipeline or an update to the existing ci/pipelines, would require
additional permissions against the Concourse framework.  If I am mistaken,
apologies.
  I suppose one could modify the existing pipeline job scripts to include
additional work, but I am disinclined to include any exploratory testing as
part of an existing test script, it being volatile by intent.
  The thought I had was to deploy a new, temporary pipeline to the staging
area, so as not to dirty the existing main/develop pipeline.  If there is a
better approach, I'm certainly open to alternatives.

On Mon, Jul 2, 2018 at 12:34 PM, Alexander Murmann 
wrote:

> Hi Patrick,
>
> The pipeline definition is in ci/pipelines. is that what you are looking
> for or do you need access to push pipeline changes?
>
> On Mon, Jul 2, 2018 at 12:08 PM, Patrick Rhomberg 
> wrote:
>
> > Hello all.
> >
> >   I'm currently investigating the state of our FlakyTest consumption,
> > believing that a lot of these markers are no longer accurate and that the
> > annotated tests deserve promotion to the actual test jobs.  [1]
> >   So as not to prematurely reintroduce flaky tests to the main body of
> the
> > pipeline, I would like to run those tests to abundance overnight to build
> > confidence in the tests performance.  Ideally, this would be in the
> actual
> > testing environment we use elsewhere, such as the Staging pipeline.
> >   To that end, I am requesting permissions to access and modify the
> Apache
> > Geode pipelines.
> >   Thank you.
> >
> > Imagination is Change.
> > ~Patrick Rhomberg
> >
> > [1] According to the script used to build the develop-metrics "pipeline",
> > there have only been 10 (of ~90) flaky test classes that produced
> failures
> > in the last 114 (currently all) FlakyTest job runs.
> > See
> > https://concourse.apachegeode-ci.info/teams/main/pipelines/
> > develop-metrics/jobs/GeodeFlakyTestMetrics/builds/48
> > and
> > others
> >
>

Re: Rat failure

[Anthony Baker]

The GEODE_USER_DIR on jenkins is set to the workspace so it’s leaving behind a 
notification file that causes rat to fail.

Anthony


> On Jul 2, 2018, at 9:13 AM, Kirk Lund  wrote:
> 
> Here's the rat failure on develop. I'm not sure what to make of it or what
> changed...
> 
> Unapproved licenses:
> 
> 
> /home/jenkins/jenkins-slave/workspace/Geode-nightly/notifications/4.8/release-features.rendered

Re: Requesting Pipeline Permissions

[Alexander Murmann]

Hi Patrick,

The pipeline definition is in ci/pipelines. is that what you are looking
for or do you need access to push pipeline changes?

On Mon, Jul 2, 2018 at 12:08 PM, Patrick Rhomberg 
wrote:

> Hello all.
>
>   I'm currently investigating the state of our FlakyTest consumption,
> believing that a lot of these markers are no longer accurate and that the
> annotated tests deserve promotion to the actual test jobs.  [1]
>   So as not to prematurely reintroduce flaky tests to the main body of the
> pipeline, I would like to run those tests to abundance overnight to build
> confidence in the tests performance.  Ideally, this would be in the actual
> testing environment we use elsewhere, such as the Staging pipeline.
>   To that end, I am requesting permissions to access and modify the Apache
> Geode pipelines.
>   Thank you.
>
> Imagination is Change.
> ~Patrick Rhomberg
>
> [1] According to the script used to build the develop-metrics "pipeline",
> there have only been 10 (of ~90) flaky test classes that produced failures
> in the last 114 (currently all) FlakyTest job runs.
> See
> https://concourse.apachegeode-ci.info/teams/main/pipelines/
> develop-metrics/jobs/GeodeFlakyTestMetrics/builds/48
> and
> others
>

Requesting Pipeline Permissions

[Patrick Rhomberg]

Hello all.

  I'm currently investigating the state of our FlakyTest consumption,
believing that a lot of these markers are no longer accurate and that the
annotated tests deserve promotion to the actual test jobs.  [1]
  So as not to prematurely reintroduce flaky tests to the main body of the
pipeline, I would like to run those tests to abundance overnight to build
confidence in the tests performance.  Ideally, this would be in the actual
testing environment we use elsewhere, such as the Staging pipeline.
  To that end, I am requesting permissions to access and modify the Apache
Geode pipelines.
  Thank you.

Imagination is Change.
~Patrick Rhomberg

[1] According to the script used to build the develop-metrics "pipeline",
there have only been 10 (of ~90) flaky test classes that produced failures
in the last 114 (currently all) FlakyTest job runs.
See
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop-metrics/jobs/GeodeFlakyTestMetrics/builds/48
and
others

Re: trying to implement SSL configuration

[Udo Kohlmeyer]

Hi there Liron,

Given that if you set a connection per thread, and by that I assume you 
mean that you set the min size on the thread pool to 0, you will incur 
the overhead of SSL negotiation EVERY time you create a connection.


Now I'm not sure what your thread pool configuration is, I'm only really 
make a wild educated guess.


Any possibility you could share your configuration with us? That would 
include thread-pool config, etc


--Udo


On 7/2/18 09:06, Anthony Baker wrote:

Why did you change the number of threads to 0 (and which setting did you 
change)?  AFAIK this is not a requirement.

Anthony



On Jul 1, 2018, at 10:29 PM, Liron Ben Ari  wrote:

Hi again...
After some functional test on the SSL configuration, we saw degradation of 300% 
on performance!!
Does anyone have an experience?
Is there a some special tuning that I can do?

We used this In our configuration - from documentation it looks like this is 
the only possible option to use...
(we must use the "all" option according to the GPRD regulations...)

ssl-enabled-components=all
ssl-protocols=any
ssl-ciphers=SSL_RSA_WITH_NULL_SHA
we have also change the number of threads to 0 (so it will be thread per 
connection - there was no other way...)


thanks a lot for any help :)

-Original Message-
From: Liron Ben Ari
Sent: Sunday, June 24, 2018 12:58 PM
To: dev@geode.apache.org 
Cc: Gregory Vortman mailto:gregory.vort...@amdocs.com>>
Subject: RE: trying to implement SSL configuration

Thanks a lot for your respond Ryan,
I've used the ssl-enabled-components=all parameter.
All my c++ clients are able to connect to the locator and to send ssl events..
I have another java client that connects to the locator and I gave him the same 
parameters...
I will try changing it and will update :) thanks

Here are the parameters  I used for the server side:

ssl-enabled-components=all
ssl-protocols=any
ssl-ciphers=SSL_RSA_WITH_NULL_SHA
ssl-keystore-type=PKCS12
ssl-keystore=/users/xpiwrk1/Amdocs-Test-CA-simple/pki/private/test1.p12
ssl-keystore-password=*
ssl-truststore-type=JKS
ssl-truststore=/users/xpiwrk1/Amdocs-Test-CA-simple/Amdocs-Test-CA-simple.jks
ssl-truststore-password=changeit

-Original Message-
From: Ryan McMahon [mailto:rmcma...@pivotal.io ]
Sent: Wednesday, June 20, 2018 6:57 PM
To: dev@geode.apache.org 
Subject: Re: trying to implement SSL configuration

Hi Liron,


The first thing that jumps out to me when you say that GFSH could not connect 
to the JMX manager is that you need to have `jmx` in addition to `locator` in 
your `ssl-enabled-components` Geode system property.  For example, you'd need 
ssl-enabled-components=locator,jmx at a minimum for GFSH to connect.  it's a 
bit different if you pass --use-http to your `connect` command, but it doesn't 
appear you are doing that.


Ryan

On Wed, Jun 20, 2018 at 8:46 AM, Liron Ben Ari mailto:liron.ben...@amdocs.com>>
wrote:


Hi ,
Well , I managed!! All my processes are talking with SSL configuration
(hip hip Horay ☺) I figure out – that I need client authentication and
server authentication in the server certificate EKU , and that I need
a single  depth hierarchy , I am not sure it will be the case when I
wil need to implement it in the customer site…

Does anyone have id why it was used like this?


Last question…
I am trying to configure the gfsh to connect to my locator.
I’ve added to the connect command the needed properties…


native" C++ interaction have a look at geode-native/cppcache/

integration-test/testThinClientSSL
This should provide an example of connecting with SSL enabled...

EB

On Tue, Jun 12, 2018 at 2:48 AM, Liron Ben Ari
mailto:liron.ben...@amdocs.com>> wrote:

We check  - the PKCS12 works  - (as  we saw it in the s_client) It
looks like the server did not found  a valid certificate...

Maybe you have a working example? When the client is native c++?

Thanks!!

-Original Message-
From: Liron Ben Ari
Sent: Tuesday, June 12, 2018 11:25 AM
To: Udo Kohlmeyer
mailto:ukohlme...@pivotal.io>>;
dev@geode.apache.org;
u...@geode.apache.org 
Cc: Gregory Vortman >; Vladi Polonsky
mailto:vladi.polon...@amdocs.com>>; Alon
Bar-Lev mailto:alon.bar...@amdocs.com>>
Subject: RE: trying to implement SSL configuration

Hi ,
Thanks you for the quick respond.
So according to the link you send, the keystore type is jks as well.
I will try  and update...
But according the client configuration (I found this document for it:
http://pubs.vmware.com/vfabric53/topic/com.vmware.
ICbase/PDF/vfabric-gemfire-nc-ug-7.0.1.pdf)

The  keystore for the native client should be in PEM format.



-Original Message-
From: Udo Kohlmeyer [mailto:ukohlme...@pivotal.io]
Sent: Tuesday, June 12, 2018 1:49 AM
To: dev@geode.apache.org; Liron Ben Ari <
liron.ben...@amdocs.com>;

Rat failure

[Kirk Lund]

Here's the rat failure on develop. I'm not sure what to make of it or what
changed...

Unapproved licenses:


/home/jenkins/jenkins-slave/workspace/Geode-nightly/notifications/4.8/release-features.rendered

Re: trying to implement SSL configuration

[Anthony Baker]

Why did you change the number of threads to 0 (and which setting did you 
change)?  AFAIK this is not a requirement.

Anthony


> On Jul 1, 2018, at 10:29 PM, Liron Ben Ari  wrote:
> 
> Hi again...
> After some functional test on the SSL configuration, we saw degradation of 
> 300% on performance!!
> Does anyone have an experience?
> Is there a some special tuning that I can do?
> 
> We used this In our configuration - from documentation it looks like this is 
> the only possible option to use...
> (we must use the "all" option according to the GPRD regulations...)
> 
> ssl-enabled-components=all
> ssl-protocols=any
> ssl-ciphers=SSL_RSA_WITH_NULL_SHA
> we have also change the number of threads to 0 (so it will be thread per 
> connection - there was no other way...)
> 
> 
> thanks a lot for any help :)
> 
> -Original Message-
> From: Liron Ben Ari 
> Sent: Sunday, June 24, 2018 12:58 PM
> To: dev@geode.apache.org 
> Cc: Gregory Vortman  >
> Subject: RE: trying to implement SSL configuration
> 
> Thanks a lot for your respond Ryan,
> I've used the ssl-enabled-components=all parameter.
> All my c++ clients are able to connect to the locator and to send ssl events..
> I have another java client that connects to the locator and I gave him the 
> same parameters...
> I will try changing it and will update :) thanks
> 
> Here are the parameters  I used for the server side:
> 
> ssl-enabled-components=all
> ssl-protocols=any
> ssl-ciphers=SSL_RSA_WITH_NULL_SHA
> ssl-keystore-type=PKCS12
> ssl-keystore=/users/xpiwrk1/Amdocs-Test-CA-simple/pki/private/test1.p12
> ssl-keystore-password=*
> ssl-truststore-type=JKS
> ssl-truststore=/users/xpiwrk1/Amdocs-Test-CA-simple/Amdocs-Test-CA-simple.jks
> ssl-truststore-password=changeit
> 
> -Original Message-
> From: Ryan McMahon [mailto:rmcma...@pivotal.io ]
> Sent: Wednesday, June 20, 2018 6:57 PM
> To: dev@geode.apache.org 
> Subject: Re: trying to implement SSL configuration
> 
> Hi Liron,
> 
> 
> The first thing that jumps out to me when you say that GFSH could not connect 
> to the JMX manager is that you need to have `jmx` in addition to `locator` in 
> your `ssl-enabled-components` Geode system property.  For example, you'd need 
> ssl-enabled-components=locator,jmx at a minimum for GFSH to connect.  it's a 
> bit different if you pass --use-http to your `connect` command, but it 
> doesn't appear you are doing that.
> 
> 
> Ryan
> 
> On Wed, Jun 20, 2018 at 8:46 AM, Liron Ben Ari  >
> wrote:
> 
>> Hi ,
>> Well , I managed!! All my processes are talking with SSL configuration 
>> (hip hip Horay ☺) I figure out – that I need client authentication and 
>> server authentication in the server certificate EKU , and that I need 
>> a single  depth hierarchy , I am not sure it will be the case when I 
>> wil need to implement it in the customer site…
>> 
>> Does anyone have id why it was used like this?
>> 
>> 
>> Last question…
>> I am trying to configure the gfsh to connect to my locator.
>> I’ve added to the connect command the needed properties…
>> 
> native" C++ interaction have a look at geode-native/cppcache/ 
>> integration-test/testThinClientSSL
>> This should provide an example of connecting with SSL enabled...
>> 
>> EB
>> 
>> On Tue, Jun 12, 2018 at 2:48 AM, Liron Ben Ari 
>> mailto:liron.ben...@amdocs.com>> wrote:
>> 
>> We check  - the PKCS12 works  - (as  we saw it in the s_client) It 
>> looks like the server did not found  a valid certificate...
>> 
>> Maybe you have a working example? When the client is native c++?
>> 
>> Thanks!!
>> 
>> -Original Message-
>> From: Liron Ben Ari
>> Sent: Tuesday, June 12, 2018 11:25 AM
>> To: Udo Kohlmeyer
>> mailto:ukohlme...@pivotal.io>>;
>> dev@geode.apache.org;
>> u...@geode.apache.org 
>> Cc: Gregory Vortman > gregory.vort...@amdocs.com>>; Vladi Polonsky 
>> mailto:vladi.polon...@amdocs.com>>; Alon 
>> Bar-Lev mailto:alon.bar...@amdocs.com>>
>> Subject: RE: trying to implement SSL configuration
>> 
>> Hi ,
>> Thanks you for the quick respond.
>> So according to the link you send, the keystore type is jks as well.
>> I will try  and update...
>> But according the client configuration (I found this document for it:
>> http://pubs.vmware.com/vfabric53/topic/com.vmware.
>> ICbase/PDF/vfabric-gemfire-nc-ug-7.0.1.pdf)
>> 
>> The  keystore for the native client should be in PEM format.
>> 
>> 
>> 
>> -Original Message-
>> From: Udo Kohlmeyer [mailto:ukohlme...@pivotal.io> ukohlme...@pivotal.io>]
>> Sent: Tuesday, June 12, 2018 1:49 AM
>> To: dev@geode.apache.org; Liron Ben Ari < 
>> liron.ben...@amdocs.com>;
>> u...@geode.apache.org
>> Cc: Gregory Vortman > gregory.vort...@amdocs.com>>; Vladi