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

[Apache Jenkins Server]

See 

Build failed in Jenkins: Geode-nightly #1047

[Apache Jenkins Server]

See 

--
[...truncated 104.00 KB...]
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at 
org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:116)
at 
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:94)
at 
org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:105)
at 
org.apache.geode.management.internal.cli.commands.DestroyIndexIfExistsTest.destroyIndexIfExists(DestroyIndexIfExistsTest.java:45)

org.apache.geode.management.internal.cli.commands.GfshStartLocatorLogTest > 
bannerOnlyLogsOnce FAILED
org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at 
org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:116)
at 
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:94)
at 
org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:105)
at 
org.apache.geode.management.internal.cli.commands.GfshStartLocatorLogTest.getExecutionLogs(GfshStartLocatorLogTest.java:53)
at 
org.apache.geode.management.internal.cli.commands.GfshStartLocatorLogTest.bannerOnlyLogsOnce(GfshStartLocatorLogTest.java:41)

org.apache.geode.management.internal.cli.commands.GfshStartLocatorLogTest > 
startupConfigsOnlyLogsOnce FAILED
org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at 
org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:116)
at 
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:94)
at 
org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:105)
at 
org.apache.geode.management.internal.cli.commands.GfshStartLocatorLogTest.getExecutionLogs(GfshStartLocatorLogTest.java:53)
at 
org.apache.geode.management.internal.cli.commands.GfshStartLocatorLogTest.startupConfigsOnlyLogsOnce(GfshStartLocatorLogTest.java:48)

org.apache.geode.management.internal.cli.commands.StatusLocatorRealGfshTest > 
statusLocatorSucceedsWhenConnected FAILED
org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at 
org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:116)
at 
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:94)
at 
org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:105)
at 
org.apache.geode.management.internal.cli.commands.StatusLocatorRealGfshTest.statusLocatorSucceedsWhenConnected(StatusLocatorRealGfshTest.java:32)

org.apache.geode.management.internal.cli.commands.StatusLocatorRealGfshTest > 
statusLocatorFailsWhenNotConnected FAILED
org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at 
org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:116)
at 
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:94)
at 
org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:105)
at 
org.apache.geode.management.internal.cli.commands.StatusLocatorRealGfshTest.statusLocatorFailsWhenNotConnected(StatusLocatorRealGfshTest.java:39)

org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
 > onlineStatusCommandShouldSucceedWhenConnected_locator_host_and_port FAILED
org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
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/IntegrationTest/builds/50

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/IntegrationTest/builds/49

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

Errored: apache/geode#5264 (develop - 8d86830)

[Travis CI]

Build Update for apache/geode
-

Build: #5264
Status: Errored

Duration: 49 minutes and 58 seconds
Commit: 8d86830 (develop)
Author: Xiaojian Zhou
Message: GEODE-4088: add a dunit test to show the client region keySet() in TX 
(#1159)

View the changeset: 
https://github.com/apache/geode/compare/fdcdbc0d0a77...8d868303d927

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/318236949?utm_source=email_medium=notification

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #770 was SUCCESSFUL (with 2324 tests). Change made by John Blum.

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #770 was successful.
---
Scheduled with changes by John Blum.
2326 tests in total.

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




--
Code Changes
--
John Blum (ba841a3473a4526cc4a7a954c545b40b70e21cf9):

>DATAGEODE-71 - Change all com.gemstone.gemfire package references in the 
>RegionDataAccessTracingAspect Pointcuts to org.apache.geode.

John Blum (338aa45f981f0c738f61743812a48779461edc37):

>DATAGEODE-73 - Fix race condition between ContinuousQuery registration and 
>EnableClusterConfiguration Region creation.

John Blum (2daf115aa753fcd5fd79f915614783cd933739fc):

>DATAGEODE-75 - Enable the spring.data.gemfire.name property to be used in 
>addition to spring.data.gemfire.cache.name for naming members of the cluster.



--
This message is automatically generated by Atlassian Bamboo

Re: Geode Jira/GitHub Integration configuration changes

[William Markito Oliveira]

+1 for removing the diff - Link to the PR should be good enough.

On Mon, Dec 18, 2017 at 1:18 PM, Jacob Barrett  wrote:

> +1 for reducing noise!
>
> On Mon, Dec 18, 2017 at 10:03 AM Joey McAllister 
> wrote:
>
> > (Er, from JIRA ticket comments, that is.)
> >
> > On Mon, Dec 18, 2017 at 10:02 AM Joey McAllister  >
> > wrote:
> >
> > > +1 to removing the diffs from JIRA tickets.
> > >
> > > On Mon, Dec 18, 2017 at 9:58 AM Dan Smith  wrote:
> > >
> > >> Hi Kirk,
> > >>
> > >> I think this is will probably require a request to infra. You can
> file a
> > >> JIRA with infra assuming we have consensus to get rid of the diffs
> (huge
> > >> +1
> > >> from me:)
> > >>
> > >> Also, please don't cross post with private@geode. The private list
> > should
> > >> *only* be used for things that can't be discussed publicly.
> > >>
> > >> -Dan
> > >>
> > >> https://www.apache.org/dev/infra-contact
> > >>
> > >> On Mon, Dec 18, 2017 at 9:43 AM, Kirk Lund  wrote:
> > >>
> > >> > Since we switched to GitBox for Geode, all Pull Requests are
> resulting
> > >> in
> > >> > huge diffs being posted to the comments on Geode Jira tickets. Some
> of
> > >> > these are resulting in hangs trying to open certain Jira tickets.
> I'd
> > >> like
> > >> > to determine what our options are for changing how this is
> configured.
> > >> >
> > >> > I looked through all of the options in the administration screens
> for
> > >> > Geode Jira but couldn't find anything other than a link to INFRA
> > GitHub
> > >> > Integration that I don't have permission to access (
> > >> >
> > >>
> > https://issues.apache.org/jira/plugins/servlet/project-
> config/GEODE/fields
> > >> > -- search down for "GitHub Integration").
> > >> >
> > >> > Does anyone know where to change this configuration or is this a
> > request
> > >> > that needs to go to ASF INFRA?
> > >> >
> > >> > Thanks,
> > >> > Kirk
> > >> >
> > >>
> > >
> >
>

Re: Geode Jira/GitHub Integration configuration changes

[Joey McAllister]

(Er, from JIRA ticket comments, that is.)

On Mon, Dec 18, 2017 at 10:02 AM Joey McAllister 
wrote:

> +1 to removing the diffs from JIRA tickets.
>
> On Mon, Dec 18, 2017 at 9:58 AM Dan Smith  wrote:
>
>> Hi Kirk,
>>
>> I think this is will probably require a request to infra. You can file a
>> JIRA with infra assuming we have consensus to get rid of the diffs (huge
>> +1
>> from me:)
>>
>> Also, please don't cross post with private@geode. The private list should
>> *only* be used for things that can't be discussed publicly.
>>
>> -Dan
>>
>> https://www.apache.org/dev/infra-contact
>>
>> On Mon, Dec 18, 2017 at 9:43 AM, Kirk Lund  wrote:
>>
>> > Since we switched to GitBox for Geode, all Pull Requests are resulting
>> in
>> > huge diffs being posted to the comments on Geode Jira tickets. Some of
>> > these are resulting in hangs trying to open certain Jira tickets. I'd
>> like
>> > to determine what our options are for changing how this is configured.
>> >
>> > I looked through all of the options in the administration screens for
>> > Geode Jira but couldn't find anything other than a link to INFRA GitHub
>> > Integration that I don't have permission to access (
>> >
>> https://issues.apache.org/jira/plugins/servlet/project-config/GEODE/fields
>> > -- search down for "GitHub Integration").
>> >
>> > Does anyone know where to change this configuration or is this a request
>> > that needs to go to ASF INFRA?
>> >
>> > Thanks,
>> > Kirk
>> >
>>
>

Re: Geode Jira/GitHub Integration configuration changes

[Joey McAllister]

+1 to removing the diffs from JIRA tickets.

On Mon, Dec 18, 2017 at 9:58 AM Dan Smith  wrote:

> Hi Kirk,
>
> I think this is will probably require a request to infra. You can file a
> JIRA with infra assuming we have consensus to get rid of the diffs (huge +1
> from me:)
>
> Also, please don't cross post with private@geode. The private list should
> *only* be used for things that can't be discussed publicly.
>
> -Dan
>
> https://www.apache.org/dev/infra-contact
>
> On Mon, Dec 18, 2017 at 9:43 AM, Kirk Lund  wrote:
>
> > Since we switched to GitBox for Geode, all Pull Requests are resulting in
> > huge diffs being posted to the comments on Geode Jira tickets. Some of
> > these are resulting in hangs trying to open certain Jira tickets. I'd
> like
> > to determine what our options are for changing how this is configured.
> >
> > I looked through all of the options in the administration screens for
> > Geode Jira but couldn't find anything other than a link to INFRA GitHub
> > Integration that I don't have permission to access (
> >
> https://issues.apache.org/jira/plugins/servlet/project-config/GEODE/fields
> > -- search down for "GitHub Integration").
> >
> > Does anyone know where to change this configuration or is this a request
> > that needs to go to ASF INFRA?
> >
> > Thanks,
> > Kirk
> >
>

Re: Geode Jira/GitHub Integration configuration changes

[Dan Smith]

Hi Kirk,

I think this is will probably require a request to infra. You can file a
JIRA with infra assuming we have consensus to get rid of the diffs (huge +1
from me:)

Also, please don't cross post with private@geode. The private list should
*only* be used for things that can't be discussed publicly.

-Dan

https://www.apache.org/dev/infra-contact

On Mon, Dec 18, 2017 at 9:43 AM, Kirk Lund  wrote:

> Since we switched to GitBox for Geode, all Pull Requests are resulting in
> huge diffs being posted to the comments on Geode Jira tickets. Some of
> these are resulting in hangs trying to open certain Jira tickets. I'd like
> to determine what our options are for changing how this is configured.
>
> I looked through all of the options in the administration screens for
> Geode Jira but couldn't find anything other than a link to INFRA GitHub
> Integration that I don't have permission to access (
> https://issues.apache.org/jira/plugins/servlet/project-config/GEODE/fields
> -- search down for "GitHub Integration").
>
> Does anyone know where to change this configuration or is this a request
> that needs to go to ASF INFRA?
>
> Thanks,
> Kirk
>

Geode Jira/GitHub Integration configuration changes

[Kirk Lund]

Since we switched to GitBox for Geode, all Pull Requests are resulting in
huge diffs being posted to the comments on Geode Jira tickets. Some of
these are resulting in hangs trying to open certain Jira tickets. I'd like
to determine what our options are for changing how this is configured.

I looked through all of the options in the administration screens for Geode
Jira but couldn't find anything other than a link to INFRA GitHub
Integration that I don't have permission to access (
https://issues.apache.org/jira/plugins/servlet/project-config/GEODE/fields
-- search down for "GitHub Integration").

Does anyone know where to change this configuration or is this a request
that needs to go to ASF INFRA?

Thanks,
Kirk

RE: Monitor the neighbour JVM using neihbour's member-timeout

[Aravind Musigumpula]

Hi Community,

Can you please give your suggestions on the below solution.

I have raised a pull request for the same : 
https://github.com/apache/geode/pull/1075 .


Thanks,
Aravind Musigumpula 

-Original Message-
From: Aravind Musigumpula 
Sent: Friday, November 03, 2017 3:23 PM
To: dev@geode.apache.org
Subject: RE: Monitor the neighbour JVM using neihbour's member-timeout

Thanks Bruce for suggestions, I will change the new variables from 
InternalDistributedMember to NetView and do changes related to backward 
compatibility.

Now I know that there is another way that member can be removed from the view 
i.e if any member is sending a message and waits for ack-wait-threshold, if 
there is no response from the target the sender will do final check and remove 
it from the view if there is still no response. 
But I don't understand how deprecating the settings member-timeout, 
ack-wait-threshold, ack-severe-alert-threshold into one will solve the problem. 
The main problem is that we want a member to survive in the view for longer 
time than others.

If we deprecate the settings into one setting and pass the setting to 
monitoring member(say A), then it will use the target member(say B which we 
want to survive in view for longer time) timeout for health monitoring and 
ack-wait-threshold to wait for the response for any message before doing final 
check.
But what if some other member(say C) which is monitoring any other member(say 
D) have the member-timeout and ack-wait-threshold some smaller values. So if 
member C messages to B, C uses the smaller value of ack-wait-threshold(which is 
of member D) to get a response and does the final check again on basis of 
smaller member-timeout. So still member B can be kicked out of the view in 
small amount of time.

I think this can be solved simply if we use the member-timeout of suspected 
member in the final check where we establish TCP connection. We don't need to 
club those three settings as well. We can set the member-timeout of a 
particular member to a higher value and the member which monitors it uses its 
own member-timeout as it is now, but during the final check it uses the 
suspected member-timeout(which is a greater value). The final check is common 
place in both the no heartbeat scenario and no response for a message scenario.

Are there any concerns around this new proposal ?


Thanks,
Aravind Musigumpula 

-Original Message-
From: Bruce Schuchardt [mailto:bschucha...@pivotal.io]
Sent: Thursday, September 07, 2017 10:42 PM
To: dev@geode.apache.org
Subject: Re: Monitor the neighbour JVM using neihbour's member-timeout

I think this might be an acceptable change though I doubt many people would 
find it useful.

It's already possible to set different member-timeouts on each node of the 
distributed system but the meaning of the setting is the inverse of what's 
proposed here, so having the current setting be different in each node is 
pretty useless.

I think the initiation of suspect processing ought to be addressed if we make 
this change.  The ack-wait-threshold and ack-severe-alert-threshold aren't 
based on the member-timeout but ought to be.  This would make it possible to 
initiate suspect processing with different timing for different nodes.  It 
would still leave the question of slow backup operations hanging:  If you're 
waiting for one node that's blocked waiting for a response from another node 
(say a node holding a backup
bucket) you are going to initiate suspect processing on the node you're waiting 
on & not those other (backup) nodes.

Rolling upgrade will also be a problem since old members aren't going to cough 
up their member-timeout settings.  What should be used as a membership timeout 
for the old members during an upgrade?

If we proceed with this idea I'd prefer that we deprecate member-timeout, 
ack-wait-threshold and ack-severe-alert-threshold and have new settings with 
the "ack" settings being multiples of the new membership timeout setting.

Concerning the PR, it isn't acceptable in its current form. 
InternalDistributedMember identifiers are often transmitted in messages and 
increasing their size affects performance.  Any new member attributes need to 
be added to NetView instead of InternalDistributedMember.


On 8/22/17 12:35 AM, Aravind Musigumpula wrote:
> Hi Team,
>
> We have a requirement to configure  different member timeout for different 
> members as we need some members to survive in the view for longer time than 
> the other the members before being kicked out of the view in case they aren't 
> responding.
>
>
> 1.   Now with the current monitoring system it is not possible to 
> determine when the member will be kicked out of the view if we configure 
> different member-timeout's for some required members.
>
> 2.   Because if a member is not responding to any heartbeat requests, the 
> member who is monitoring the non-responding member will initiate check member 
> request.
>