Re: SSL Alias Support for JMX Connections

[Owen Nichols]

Hi Juan and Sai, thank you for bringing your concern.

Geode's release process dictates a time-based schedule 
 to cut 
release branches.  The release/1.10.0 
 branch was already cut 1 
week ago, but the “critical fixes” rule does allow critical fixes to be brought 
to the release branch by proposal on the dev list, as you have done here.

If there is consensus from the Geode community that your proposed change 
satisfies the “critical fixes” rule, I will be happy to bring it to the 1.10.0 
release branch.

Regards
- Owen

> On Aug 8, 2019, at 6:53 PM, Sai Boorlagadda  wrote:
> 
> +1 for getting this into 1.10
> 
> On Thu, Aug 8, 2019 at 11:29 AM Juan José Ramos  wrote:
> 
>> I'd like to propose including the fix for *GEODE-7022 [1]* in release
>> 1.10.0.
>> The fix basically improves our own implementation of the
>> *RMIClientSocketFactory* to fully support the GEODE SSL settings, allowing
>> our users to specify a default alias when opening an RMI connection.
>> Best regards.
>> 
>> [1]: https://issues.apache.org/jira/browse/GEODE-7022
>> 
>> --
>> Juan José Ramos Cassella
>> Senior Software Engineer
>> Email: jra...@pivotal.io
>> 

Re: SSL Alias Support for JMX Connections

[Sai Boorlagadda]

+1 for getting this into 1.10

On Thu, Aug 8, 2019 at 11:29 AM Juan José Ramos  wrote:

> I'd like to propose including the fix for *GEODE-7022 [1]* in release
> 1.10.0.
> The fix basically improves our own implementation of the
> *RMIClientSocketFactory* to fully support the GEODE SSL settings, allowing
> our users to specify a default alias when opening an RMI connection.
> Best regards.
>
> [1]: https://issues.apache.org/jira/browse/GEODE-7022
>
> --
> Juan José Ramos Cassella
> Senior Software Engineer
> Email: jra...@pivotal.io
>

Re: Fix for ClassCastException when using Logback for 1.10.0

[Owen Nichols]

There appears to be consensus that this is a critical fix.

The following commit has been brought into support/1.10.0 
 as the critical fix for 
GEODE-7050 :

git cherry-pick -x e5c9c420f462149fd062847904e3435fbe99afb4 


GEODE-7050  has been marked 
as 'resolved in' 1.10.0.

-Owen

> On Aug 8, 2019, at 11:36 AM, John Blum  wrote:
> 
> +1
> 
> On Thu, Aug 8, 2019 at 11:31 AM Juan José Ramos  wrote:
> 
>> +1
>> 
>> On Thu, Aug 8, 2019 at 7:26 PM Mark Hanson  wrote:
>> 
>>> +1
>>> 
>>> I think it is valuable to make life easier for Spring Boot users.
>>> 
>>> Thanks,
>>> Mark
>>> 
 On Aug 8, 2019, at 11:24 AM, Kirk Lund  wrote:
 
 This is the last logging related fix that I'd like to propose adding to
 1.10.0
 release branch.
 
 Spring Boot adds Logback and log4j-to-slf4j to the classpath. This
 results in ClassCastExceptions if log4j-core is not excluded.
 
 This change prevents Geode from using Log4jAgent if Log4j Core is
 present but not using Log4jProvider.
 
 For example, Log4j uses SLF4JProvider instead of Log4jProvider when
 log4j-to-slf4j is in the classpath.
 
 By disabling Log4jAgent when other Log4j Providers are in use, this
 prevents problems such as ClassCastExceptions when attempting to cast
 loggers from org.apache.logging.slf4j.SLF4JLogger to
 org.apache.logging.log4j.core.Logger to get the LoggerConfig or
 LoggerContext.
 
 PR: https://github.com/apache/geode/pull/3892
 GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider
 https://issues.apache.org/jira/browse/GEODE-7050
 
 Thanks,
 Kirk and Aaron
>>> 
>>> 
>> 
>> --
>> Juan José Ramos Cassella
>> Senior Software Engineer
>> Email: jra...@pivotal.io
>> 
> 
> 
> -- 
> -John
> john.blum10101 (skype)

Re: Unit tests are hanging?

[Ryan McMahon]

I have a PR up for this now.
https://github.com/apache/geode/pull/3900

It bumps the timeout to 20 minutes but also changes the CALL_STACK_TIMEOUT
to be 1140 seconds (19 minutes).  The latter configuration parameter
controls when we declare the task "hung" and dump stacks.  We were not
dumping stacks at all before these changes because the value was 1800
seconds which is well above the timeout of 10 minutes.  With my proposed
change we will dump stacks before the task times out so we will have
something to look at in the test artifacts to identify the hang.

Thanks,
Ryan

On Thu, Aug 8, 2019 at 11:28 AM Ryan McMahon  wrote:

> Looks like we have a general consensus from the community.  I'll go ahead
> and make a PR for the changes.
>
> Thanks,
> Ryan
>
> On Thu, Aug 8, 2019 at 11:03 AM Juan José Ramos  wrote:
>
>> +1
>>
>> On Thu, Aug 8, 2019 at 6:55 PM Kirk Lund  wrote:
>>
>> > +1
>> >
>> > On Thu, Aug 8, 2019 at 10:14 AM Dan Smith  wrote:
>> >
>> > > > With all that, I propose we permanently bump the timeouts on
>> UnitTestX
>> > > jobs
>> > > > across the board (main pipeline, PR pipeline, etc) from 10 to 20
>> > minutes
>> > > to
>> > > > be more tolerant of these types of degradations.
>> > > >
>> > >
>> > > +1
>> > >
>> > > -Dan
>> > >
>> >
>>
>>
>> --
>> Juan José Ramos Cassella
>> Senior Technical Support Engineer
>> Email: jra...@pivotal.io
>> Office#: +353 21 4238611
>> Mobile#: +353 87 2074066
>> After Hours Contact#: +1 877 477 2269
>> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
>> How to upload artifacts:
>> https://support.pivotal.io/hc/en-us/articles/204369073
>> How to escalate a ticket:
>> https://support.pivotal.io/hc/en-us/articles/203809556
>>
>> [image: support]  [image: twitter]
>>  [image: linkedin]
>>  [image: facebook]
>>  [image: google plus]
>>  [image: youtube]
>> > >
>>
>

Re: geode-native ipv6

[Blake Bender]

This chunk of code in the client handshake code leads me to believe it is
still IPv4 only.  Won't say it's definitive, cause I'm not 100% certain
hostaddr is used on the server side, but still...

// writing first 4 bytes of the address. This will be same until
// IPV6 support is added in the client
uint32_t temp;
memcpy(, hostAddr, 4);
m_memID.writeInt(static_cast(temp));


On Thu, Aug 8, 2019 at 1:18 PM Jacob Barrett  wrote:

> We are on the latest ACE.
>
> > On Aug 8, 2019, at 9:56 AM, Mark Hanson  wrote:
> >
> > The latest ACE framework seems to have support, but I don’t know how far
> off latest we are. I don’t think we test anything in an IPv6 context, so I
> would say no that we don’t officially support it in the client. Given some
> time, I could do some testing..
> >
> > Thanks,
> > Mark
> >
> >> On Aug 8, 2019, at 7:35 AM, Blake Bender  wrote:
> >>
> >> I'm sure someone will chime in with a more definitive answer, but I'm
> >> pretty certain the answer is no, sorry.
> >>
> >> Thanks,
> >>
> >> Blake
> >>
> >>
> >>> On Thu, Aug 8, 2019 at 4:28 AM Mario Ivanac 
> wrote:
> >>>
> >>> Hi,
> >>>
> >>>
> >>> can you tell me does geode-native client support ipv6?
> >>>
> >>>
> >>> BR,
> >>>
> >>> Mario
> >>>
> >
>

Re: geode-native ipv6

[Mark Hanson]

I just tried to connect to Geode with the native client and it did not go well. 
 It exceptioned with an illegal argument error.

That said, it “seems" like it might not be complicated to make it IPv6 
compliant.

Thanks,
Mark

> On Aug 8, 2019, at 9:56 AM, Mark Hanson  wrote:
> 
> The latest ACE framework seems to have support, but I don’t know how far off 
> latest we are. I don’t think we test anything in an IPv6 context, so I would 
> say no that we don’t officially support it in the client. Given some time, I 
> could do some testing..
> 
> Thanks,
> Mark
> 
>> On Aug 8, 2019, at 7:35 AM, Blake Bender  wrote:
>> 
>> I'm sure someone will chime in with a more definitive answer, but I'm
>> pretty certain the answer is no, sorry.
>> 
>> Thanks,
>> 
>> Blake
>> 
>> 
>> On Thu, Aug 8, 2019 at 4:28 AM Mario Ivanac  wrote:
>> 
>>> Hi,
>>> 
>>> 
>>> can you tell me does geode-native client support ipv6?
>>> 
>>> 
>>> BR,
>>> 
>>> Mario
>>> 
> 

Re: geode-native ipv6

[Jacob Barrett]

We are on the latest ACE.

> On Aug 8, 2019, at 9:56 AM, Mark Hanson  wrote:
> 
> The latest ACE framework seems to have support, but I don’t know how far off 
> latest we are. I don’t think we test anything in an IPv6 context, so I would 
> say no that we don’t officially support it in the client. Given some time, I 
> could do some testing..
> 
> Thanks,
> Mark
> 
>> On Aug 8, 2019, at 7:35 AM, Blake Bender  wrote:
>> 
>> I'm sure someone will chime in with a more definitive answer, but I'm
>> pretty certain the answer is no, sorry.
>> 
>> Thanks,
>> 
>> Blake
>> 
>> 
>>> On Thu, Aug 8, 2019 at 4:28 AM Mario Ivanac  wrote:
>>> 
>>> Hi,
>>> 
>>> 
>>> can you tell me does geode-native client support ipv6?
>>> 
>>> 
>>> BR,
>>> 
>>> Mario
>>> 
> 

Re: Fix for ClassCastException when using Logback for 1.10.0

[John Blum]

+1

On Thu, Aug 8, 2019 at 11:31 AM Juan José Ramos  wrote:

> +1
>
> On Thu, Aug 8, 2019 at 7:26 PM Mark Hanson  wrote:
>
> > +1
> >
> > I think it is valuable to make life easier for Spring Boot users.
> >
> > Thanks,
> > Mark
> >
> > > On Aug 8, 2019, at 11:24 AM, Kirk Lund  wrote:
> > >
> > > This is the last logging related fix that I'd like to propose adding to
> > > 1.10.0
> > > release branch.
> > >
> > > Spring Boot adds Logback and log4j-to-slf4j to the classpath. This
> > > results in ClassCastExceptions if log4j-core is not excluded.
> > >
> > > This change prevents Geode from using Log4jAgent if Log4j Core is
> > > present but not using Log4jProvider.
> > >
> > > For example, Log4j uses SLF4JProvider instead of Log4jProvider when
> > > log4j-to-slf4j is in the classpath.
> > >
> > > By disabling Log4jAgent when other Log4j Providers are in use, this
> > > prevents problems such as ClassCastExceptions when attempting to cast
> > > loggers from org.apache.logging.slf4j.SLF4JLogger to
> > > org.apache.logging.log4j.core.Logger to get the LoggerConfig or
> > > LoggerContext.
> > >
> > > PR: https://github.com/apache/geode/pull/3892
> > > GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider
> > > https://issues.apache.org/jira/browse/GEODE-7050
> > >
> > > Thanks,
> > > Kirk and Aaron
> >
> >
>
> --
> Juan José Ramos Cassella
> Senior Software Engineer
> Email: jra...@pivotal.io
>


-- 
-John
john.blum10101 (skype)

Re: Fix for ClassCastException when using Logback for 1.10.0

[Juan José Ramos]

+1

On Thu, Aug 8, 2019 at 7:26 PM Mark Hanson  wrote:

> +1
>
> I think it is valuable to make life easier for Spring Boot users.
>
> Thanks,
> Mark
>
> > On Aug 8, 2019, at 11:24 AM, Kirk Lund  wrote:
> >
> > This is the last logging related fix that I'd like to propose adding to
> > 1.10.0
> > release branch.
> >
> > Spring Boot adds Logback and log4j-to-slf4j to the classpath. This
> > results in ClassCastExceptions if log4j-core is not excluded.
> >
> > This change prevents Geode from using Log4jAgent if Log4j Core is
> > present but not using Log4jProvider.
> >
> > For example, Log4j uses SLF4JProvider instead of Log4jProvider when
> > log4j-to-slf4j is in the classpath.
> >
> > By disabling Log4jAgent when other Log4j Providers are in use, this
> > prevents problems such as ClassCastExceptions when attempting to cast
> > loggers from org.apache.logging.slf4j.SLF4JLogger to
> > org.apache.logging.log4j.core.Logger to get the LoggerConfig or
> > LoggerContext.
> >
> > PR: https://github.com/apache/geode/pull/3892
> > GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider
> > https://issues.apache.org/jira/browse/GEODE-7050
> >
> > Thanks,
> > Kirk and Aaron
>
>

-- 
Juan José Ramos Cassella
Senior Software Engineer
Email: jra...@pivotal.io

SSL Alias Support for JMX Connections

[Juan José Ramos]

I'd like to propose including the fix for *GEODE-7022 [1]* in release
1.10.0.
The fix basically improves our own implementation of the
*RMIClientSocketFactory* to fully support the GEODE SSL settings, allowing
our users to specify a default alias when opening an RMI connection.
Best regards.

[1]: https://issues.apache.org/jira/browse/GEODE-7022

-- 
Juan José Ramos Cassella
Senior Software Engineer
Email: jra...@pivotal.io

Re: Unit tests are hanging?

[Ryan McMahon]

Looks like we have a general consensus from the community.  I'll go ahead
and make a PR for the changes.

Thanks,
Ryan

On Thu, Aug 8, 2019 at 11:03 AM Juan José Ramos  wrote:

> +1
>
> On Thu, Aug 8, 2019 at 6:55 PM Kirk Lund  wrote:
>
> > +1
> >
> > On Thu, Aug 8, 2019 at 10:14 AM Dan Smith  wrote:
> >
> > > > With all that, I propose we permanently bump the timeouts on
> UnitTestX
> > > jobs
> > > > across the board (main pipeline, PR pipeline, etc) from 10 to 20
> > minutes
> > > to
> > > > be more tolerant of these types of degradations.
> > > >
> > >
> > > +1
> > >
> > > -Dan
> > >
> >
>
>
> --
> Juan José Ramos Cassella
> Senior Technical Support Engineer
> Email: jra...@pivotal.io
> Office#: +353 21 4238611
> Mobile#: +353 87 2074066
> After Hours Contact#: +1 877 477 2269
> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> How to upload artifacts:
> https://support.pivotal.io/hc/en-us/articles/204369073
> How to escalate a ticket:
> https://support.pivotal.io/hc/en-us/articles/203809556
>
> [image: support]  [image: twitter]
>  [image: linkedin]
>  [image: facebook]
>  [image: google plus]
>  [image: youtube]
> 
>

Re: Fix for ClassCastException when using Logback for 1.10.0

[Mark Hanson]

+1 

I think it is valuable to make life easier for Spring Boot users.

Thanks,
Mark

> On Aug 8, 2019, at 11:24 AM, Kirk Lund  wrote:
> 
> This is the last logging related fix that I'd like to propose adding to
> 1.10.0
> release branch.
> 
> Spring Boot adds Logback and log4j-to-slf4j to the classpath. This
> results in ClassCastExceptions if log4j-core is not excluded.
> 
> This change prevents Geode from using Log4jAgent if Log4j Core is
> present but not using Log4jProvider.
> 
> For example, Log4j uses SLF4JProvider instead of Log4jProvider when
> log4j-to-slf4j is in the classpath.
> 
> By disabling Log4jAgent when other Log4j Providers are in use, this
> prevents problems such as ClassCastExceptions when attempting to cast
> loggers from org.apache.logging.slf4j.SLF4JLogger to
> org.apache.logging.log4j.core.Logger to get the LoggerConfig or
> LoggerContext.
> 
> PR: https://github.com/apache/geode/pull/3892
> GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider
> https://issues.apache.org/jira/browse/GEODE-7050
> 
> Thanks,
> Kirk and Aaron

Fix for ClassCastException when using Logback for 1.10.0

[Kirk Lund]

This is the last logging related fix that I'd like to propose adding to
1.10.0
release branch.

Spring Boot adds Logback and log4j-to-slf4j to the classpath. This
results in ClassCastExceptions if log4j-core is not excluded.

This change prevents Geode from using Log4jAgent if Log4j Core is
present but not using Log4jProvider.

For example, Log4j uses SLF4JProvider instead of Log4jProvider when
log4j-to-slf4j is in the classpath.

By disabling Log4jAgent when other Log4j Providers are in use, this
prevents problems such as ClassCastExceptions when attempting to cast
loggers from org.apache.logging.slf4j.SLF4JLogger to
org.apache.logging.log4j.core.Logger to get the LoggerConfig or
LoggerContext.

PR: https://github.com/apache/geode/pull/3892
GEODE-7050: Use Log4jAgent only if Log4j is using Log4jProvider
https://issues.apache.org/jira/browse/GEODE-7050

Thanks,
Kirk and Aaron

Re: Fix for NPE during forceDisconnect candidate for 1.10.0

[Juan José Ramos]

+1

On Thu, Aug 8, 2019 at 7:02 PM John Blum  wrote:

> +1 for Kirk's changes in 1.10.  This will be critical for SD Neuman and
> SBDG 1.3.
>
> On Thu, Aug 8, 2019 at 10:57 AM Owen Nichols  wrote:
>
> > Hi Kirk and Mark, thank you for bringing your concern.
> >
> > Our “critical fixes” rule allows critical fixes to be brought to the
> > release branch by proposal on the dev list, as you have just done.  If
> > there is consensus from the Geode community that this NPE fix satisfies
> the
> > “critical fixes” rule, Dick or I will be happy to bring it to the 1.10.0
> > release branch.
> >
> > -Owen
> >
> > > On Aug 8, 2019, at 10:54 AM, Kirk Lund  wrote:
> > >
> > > I'd like to propose including the fix for GEODE-6959 in 1.10.0.
> > >
> > > Spring Boot users are very likely to hit this NPE during
> forceDisconnect.
> > >
> > > If a custom log4j2.xml is used without specifying the Geode
> > AlertAppender,
> > > GMSMembershipManager may throw a NullPointerException when invoking
> > > AlertAppender.getInstance().stopSession() during a forceDisconnect.
> This
> > > change prevents the NullPointerException allowing forceDisconnect to
> > finish.
> > > Tests are included with this fix.
> > >
> > > PR: https://github.com/apache/geode/pull/3899
> > > GEODE-6959: NPE if AlertAppender is not defined
> > >
> > > Thanks,
> > > Kirk and Mark
> >
> >
>
> --
> -John
> john.blum10101 (skype)
>


-- 
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jra...@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556

[image: support]  [image: twitter]
 [image: linkedin]
 [image: facebook]
 [image: google plus]
 [image: youtube]

Re: Unit tests are hanging?

[Juan José Ramos]

+1

On Thu, Aug 8, 2019 at 6:55 PM Kirk Lund  wrote:

> +1
>
> On Thu, Aug 8, 2019 at 10:14 AM Dan Smith  wrote:
>
> > > With all that, I propose we permanently bump the timeouts on UnitTestX
> > jobs
> > > across the board (main pipeline, PR pipeline, etc) from 10 to 20
> minutes
> > to
> > > be more tolerant of these types of degradations.
> > >
> >
> > +1
> >
> > -Dan
> >
>


-- 
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jra...@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556

[image: support]  [image: twitter]
 [image: linkedin]
 [image: facebook]
 [image: google plus]
 [image: youtube]

Re: Fix for NPE during forceDisconnect candidate for 1.10.0

[John Blum]

+1 for Kirk's changes in 1.10.  This will be critical for SD Neuman and
SBDG 1.3.

On Thu, Aug 8, 2019 at 10:57 AM Owen Nichols  wrote:

> Hi Kirk and Mark, thank you for bringing your concern.
>
> Our “critical fixes” rule allows critical fixes to be brought to the
> release branch by proposal on the dev list, as you have just done.  If
> there is consensus from the Geode community that this NPE fix satisfies the
> “critical fixes” rule, Dick or I will be happy to bring it to the 1.10.0
> release branch.
>
> -Owen
>
> > On Aug 8, 2019, at 10:54 AM, Kirk Lund  wrote:
> >
> > I'd like to propose including the fix for GEODE-6959 in 1.10.0.
> >
> > Spring Boot users are very likely to hit this NPE during forceDisconnect.
> >
> > If a custom log4j2.xml is used without specifying the Geode
> AlertAppender,
> > GMSMembershipManager may throw a NullPointerException when invoking
> > AlertAppender.getInstance().stopSession() during a forceDisconnect. This
> > change prevents the NullPointerException allowing forceDisconnect to
> finish.
> > Tests are included with this fix.
> >
> > PR: https://github.com/apache/geode/pull/3899
> > GEODE-6959: NPE if AlertAppender is not defined
> >
> > Thanks,
> > Kirk and Mark
>
>

-- 
-John
john.blum10101 (skype)

Re: Fix for NPE during forceDisconnect candidate for 1.10.0

[Owen Nichols]

Hi Kirk and Mark, thank you for bringing your concern.

Our “critical fixes” rule allows critical fixes to be brought to the release 
branch by proposal on the dev list, as you have just done.  If there is 
consensus from the Geode community that this NPE fix satisfies the “critical 
fixes” rule, Dick or I will be happy to bring it to the 1.10.0 release branch.

-Owen

> On Aug 8, 2019, at 10:54 AM, Kirk Lund  wrote:
> 
> I'd like to propose including the fix for GEODE-6959 in 1.10.0.
> 
> Spring Boot users are very likely to hit this NPE during forceDisconnect.
> 
> If a custom log4j2.xml is used without specifying the Geode AlertAppender,
> GMSMembershipManager may throw a NullPointerException when invoking
> AlertAppender.getInstance().stopSession() during a forceDisconnect. This
> change prevents the NullPointerException allowing forceDisconnect to finish.
> Tests are included with this fix.
> 
> PR: https://github.com/apache/geode/pull/3899
> GEODE-6959: NPE if AlertAppender is not defined
> 
> Thanks,
> Kirk and Mark

Re: Unit tests are hanging?

[Kirk Lund]

+1

On Thu, Aug 8, 2019 at 10:14 AM Dan Smith  wrote:

> > With all that, I propose we permanently bump the timeouts on UnitTestX
> jobs
> > across the board (main pipeline, PR pipeline, etc) from 10 to 20 minutes
> to
> > be more tolerant of these types of degradations.
> >
>
> +1
>
> -Dan
>

Fix for NPE during forceDisconnect candidate for 1.10.0

[Kirk Lund]

I'd like to propose including the fix for GEODE-6959 in 1.10.0.

Spring Boot users are very likely to hit this NPE during forceDisconnect.

If a custom log4j2.xml is used without specifying the Geode AlertAppender,
GMSMembershipManager may throw a NullPointerException when invoking
AlertAppender.getInstance().stopSession() during a forceDisconnect. This
change prevents the NullPointerException allowing forceDisconnect to finish.
Tests are included with this fix.

PR: https://github.com/apache/geode/pull/3899
GEODE-6959: NPE if AlertAppender is not defined

Thanks,
Kirk and Mark

Re: Another change for 1.10.0 release

[Owen Nichols]

There appears to be consensus that this is a critical fix.

The following commit has been brought into support/1.10.0 
 as the critical fix for 
GEODE-7055 :

git cherry-pick -x 1438b56bf7ef44e758bb4fc157dfca2cff4e2c99 


GEODE-7055  has been marked 
as 'resolved in' 1.10.0.

-Owen

> On Aug 8, 2019, at 10:42 AM, Juan José Ramos  wrote:
> 
> +1
> 
> On Thu, Aug 8, 2019 at 6:41 PM Ryan McMahon  wrote:
> 
>> +1
>> 
>> On Thu, Aug 8, 2019 at 10:40 AM John Blum  wrote:
>> 
>>> +1 for Dan's changes.
>>> 
>>> On Thu, Aug 8, 2019 at 10:28 AM Owen Nichols 
>> wrote:
>>> 
 Hi Dan, thank you for bringing your concern.
 
 Our “critical fixes” rule allows critical fixes to be brought to the
 release branch by proposal on the dev list [as you have just done].  If
 there is consensus from the Geode community that this GEODE-7055 fix
 satisfies the “critical fixes” rule, Dick or I will be happy to bring
>> it
>>> to
 the 1.10.0 release branch.
 
 -Owen
 
 
> On Aug 8, 2019, at 10:11 AM, Dan Smith  wrote:
> 
> Hi all,
> 
> I'd like to get the fix for GEODE-7055 (Don't send failure replies
>>> from a
> P2P reader thread) into the 1.10.0 release branch.
> 
> This bug was causing a hang on startup for users of the session
 replication
> module that didn't put the session jars on the classpath of the
>>> locator.
> The hang doesn't happen with 1.9.0, so I'd I think we should make
>> sure
>>> it
> won't happen with 1.10.0 as well.
> 
> -Dan
 
 
>>> 
>>> --
>>> -John
>>> john.blum10101 (skype)
>>> 
>> 
> 
> 
> -- 
> Juan José Ramos Cassella
> Senior Technical Support Engineer
> Email: jra...@pivotal.io
> Office#: +353 21 4238611
> Mobile#: +353 87 2074066
> After Hours Contact#: +1 877 477 2269
> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> How to upload artifacts:
> https://support.pivotal.io/hc/en-us/articles/204369073
> How to escalate a ticket:
> https://support.pivotal.io/hc/en-us/articles/203809556
> 
> [image: support]  [image: twitter]
>  [image: linkedin]
>  [image: facebook]
>  [image: google plus]
>  [image: youtube]
> 

Re: Another change for 1.10.0 release

[Juan José Ramos]

+1

On Thu, Aug 8, 2019 at 6:41 PM Ryan McMahon  wrote:

> +1
>
> On Thu, Aug 8, 2019 at 10:40 AM John Blum  wrote:
>
> > +1 for Dan's changes.
> >
> > On Thu, Aug 8, 2019 at 10:28 AM Owen Nichols 
> wrote:
> >
> > > Hi Dan, thank you for bringing your concern.
> > >
> > > Our “critical fixes” rule allows critical fixes to be brought to the
> > > release branch by proposal on the dev list [as you have just done].  If
> > > there is consensus from the Geode community that this GEODE-7055 fix
> > > satisfies the “critical fixes” rule, Dick or I will be happy to bring
> it
> > to
> > > the 1.10.0 release branch.
> > >
> > > -Owen
> > >
> > >
> > > > On Aug 8, 2019, at 10:11 AM, Dan Smith  wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I'd like to get the fix for GEODE-7055 (Don't send failure replies
> > from a
> > > > P2P reader thread) into the 1.10.0 release branch.
> > > >
> > > > This bug was causing a hang on startup for users of the session
> > > replication
> > > > module that didn't put the session jars on the classpath of the
> > locator.
> > > > The hang doesn't happen with 1.9.0, so I'd I think we should make
> sure
> > it
> > > > won't happen with 1.10.0 as well.
> > > >
> > > > -Dan
> > >
> > >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>


-- 
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jra...@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556

[image: support]  [image: twitter]
 [image: linkedin]
 [image: facebook]
 [image: google plus]
 [image: youtube]

Re: Another change for 1.10.0 release

[Ryan McMahon]

+1

On Thu, Aug 8, 2019 at 10:40 AM John Blum  wrote:

> +1 for Dan's changes.
>
> On Thu, Aug 8, 2019 at 10:28 AM Owen Nichols  wrote:
>
> > Hi Dan, thank you for bringing your concern.
> >
> > Our “critical fixes” rule allows critical fixes to be brought to the
> > release branch by proposal on the dev list [as you have just done].  If
> > there is consensus from the Geode community that this GEODE-7055 fix
> > satisfies the “critical fixes” rule, Dick or I will be happy to bring it
> to
> > the 1.10.0 release branch.
> >
> > -Owen
> >
> >
> > > On Aug 8, 2019, at 10:11 AM, Dan Smith  wrote:
> > >
> > > Hi all,
> > >
> > > I'd like to get the fix for GEODE-7055 (Don't send failure replies
> from a
> > > P2P reader thread) into the 1.10.0 release branch.
> > >
> > > This bug was causing a hang on startup for users of the session
> > replication
> > > module that didn't put the session jars on the classpath of the
> locator.
> > > The hang doesn't happen with 1.9.0, so I'd I think we should make sure
> it
> > > won't happen with 1.10.0 as well.
> > >
> > > -Dan
> >
> >
>
> --
> -John
> john.blum10101 (skype)
>

Re: Another change for 1.10.0 release

[John Blum]

+1 for Dan's changes.

On Thu, Aug 8, 2019 at 10:28 AM Owen Nichols  wrote:

> Hi Dan, thank you for bringing your concern.
>
> Our “critical fixes” rule allows critical fixes to be brought to the
> release branch by proposal on the dev list [as you have just done].  If
> there is consensus from the Geode community that this GEODE-7055 fix
> satisfies the “critical fixes” rule, Dick or I will be happy to bring it to
> the 1.10.0 release branch.
>
> -Owen
>
>
> > On Aug 8, 2019, at 10:11 AM, Dan Smith  wrote:
> >
> > Hi all,
> >
> > I'd like to get the fix for GEODE-7055 (Don't send failure replies from a
> > P2P reader thread) into the 1.10.0 release branch.
> >
> > This bug was causing a hang on startup for users of the session
> replication
> > module that didn't put the session jars on the classpath of the locator.
> > The hang doesn't happen with 1.9.0, so I'd I think we should make sure it
> > won't happen with 1.10.0 as well.
> >
> > -Dan
>
>

-- 
-John
john.blum10101 (skype)

Re: Another change for 1.10.0 release

[Owen Nichols]

Hi Dan, thank you for bringing your concern.

Our “critical fixes” rule allows critical fixes to be brought to the release 
branch by proposal on the dev list [as you have just done].  If there is 
consensus from the Geode community that this GEODE-7055 fix satisfies the 
“critical fixes” rule, Dick or I will be happy to bring it to the 1.10.0 
release branch.

-Owen


> On Aug 8, 2019, at 10:11 AM, Dan Smith  wrote:
> 
> Hi all,
> 
> I'd like to get the fix for GEODE-7055 (Don't send failure replies from a
> P2P reader thread) into the 1.10.0 release branch.
> 
> This bug was causing a hang on startup for users of the session replication
> module that didn't put the session jars on the classpath of the locator.
> The hang doesn't happen with 1.9.0, so I'd I think we should make sure it
> won't happen with 1.10.0 as well.
> 
> -Dan

Re: Unit tests are hanging?

[Dan Smith]

> With all that, I propose we permanently bump the timeouts on UnitTestX jobs
> across the board (main pipeline, PR pipeline, etc) from 10 to 20 minutes to
> be more tolerant of these types of degradations.
>

+1

-Dan

Another change for 1.10.0 release

[Dan Smith]

Hi all,

I'd like to get the fix for GEODE-7055 (Don't send failure replies from a
P2P reader thread) into the 1.10.0 release branch.

This bug was causing a hang on startup for users of the session replication
module that didn't put the session jars on the classpath of the locator.
The hang doesn't happen with 1.9.0, so I'd I think we should make sure it
won't happen with 1.10.0 as well.

-Dan

Re: geode-native ipv6

[Mark Hanson]

The latest ACE framework seems to have support, but I don’t know how far off 
latest we are. I don’t think we test anything in an IPv6 context, so I would 
say no that we don’t officially support it in the client. Given some time, I 
could do some testing..

Thanks,
Mark

> On Aug 8, 2019, at 7:35 AM, Blake Bender  wrote:
> 
> I'm sure someone will chime in with a more definitive answer, but I'm
> pretty certain the answer is no, sorry.
> 
> Thanks,
> 
> Blake
> 
> 
> On Thu, Aug 8, 2019 at 4:28 AM Mario Ivanac  wrote:
> 
>> Hi,
>> 
>> 
>> can you tell me does geode-native client support ipv6?
>> 
>> 
>> BR,
>> 
>> Mario
>> 

Re: Unit tests are hanging?

[Ryan McMahon]

So we temporarily bumped the timeout from 10 minutes to 2 hours on the
UnitTestOpenJDK11 execute_tests Concourse task, originally with the
intention of logging into the heavy lifter to debug further.  However,
after doing that we see that the jobs are all succeeding in roughly the
same amount of time as they did before we started seeing these timeouts
(total job time 25-30 minutes, total execute_tests task time of 7.5ish
minutes).  This makes me think that we were seeing some sort of performance
degradation at the infrastructure level, as opposed to some recent change
to Geode which is causing the timeouts.

With all that, I propose we permanently bump the timeouts on UnitTestX jobs
across the board (main pipeline, PR pipeline, etc) from 10 to 20 minutes to
be more tolerant of these types of degradations.  Please let me know if
anyone is opposed to doing this.

Thanks,
Ryan

On Wed, Aug 7, 2019 at 11:39 AM Ryan McMahon  wrote:

> Still trying to identify the cause of the unit test hangs.stay tuned.
> For other people who might not know this, the reason the entire CI job
> fails rather than the hanging test is because we don't have any global
> test-level timeouts, so a hanging test will run up until the Concourse
> timeout is reached.  I wrote a story to explore adding test level timeouts
> so we can get actual feedback in the CI about which test is hanging without
> waiting for the whole job to timeout, downloading artifacts, looking at the
> stack dumps, etc etc.  I think we could have some reasonable global upper
> limit (30 minutes?) for any test.  We could always tune that as needed.
>
> https://issues.apache.org/jira/projects/GEODE/issues/GEODE-7057?filter=allopenissues
>
> Ryan
>
> On Wed, Aug 7, 2019 at 11:21 AM Bruce Schuchardt 
> wrote:
>
>> Yeah, that test passed on my branch in unit tests and stress tests but
>> for some reason is hanging after the merge to develop. I've pushed an
>> @Ignore for the test that you should pick up.
>>
>> On 8/7/19 10:38 AM, Kirk Lund wrote:
>> > Yep, that's the same test I'm seeing in the callstacks of my dunit tgz
>> from
>> > concourse...
>> >
>> > Started @ 2019-08-07 07:25:18.494 +
>> > 2019-08-07 07:51:25.252 +
>> >   org.apache.geode.cache30.DistributedMulticastRegionDUnitTest
>> > testMulticastAfterReconnect
>> > Ended @ 2019-08-07 08:28:16.591 +
>> >
>> > Thanks for digging into it!
>> >
>> > On Wed, Aug 7, 2019 at 10:16 AM Ryan McMahon 
>> wrote:
>> >
>> >> I think the reflection and PowerMock warnings here are probably a red
>> >> herring.  We pulled down the artifacts and found that the DUnit job is
>> >> hanging due to stuck threads in a newer DUnit test.  I am not sure why
>> it
>> >> isn't failing the test but rather failing the entire job.  I believe
>> Bruce
>> >> Schuchart is going to dig into this a bit.  Analysis from Lynn
>> >> Hughes-Godfrey:
>> >>
>> >> So, I downloaded
>> >>
>> >>
>> >>
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/961
>> >>
>> >> to
>> >>
>> >>
>> >>
>> /Users/lhughesgodfrey/Downloads/distributedtestfiles-OpenJDK8-1.11.0-SNAPSHOT.0010/geode-core/build/distributedTest
>> >>
>> >> In that callstacks directory, you'll see dunit-hangs.txt ... and this
>> >> test has been running for over an hour ...
>> >>
>> >> ```
>> >>
>> >> Started @ 2019-08-07 07:54:10.272 +
>> >>
>> >> 2019-08-07 08:22:25.440 +
>> >> org.apache.geode.cache30.DistributedMulticastRegionDUnitTest
>> >> testMulticastAfterReconnect
>> >>
>> >> Ended @ 2019-08-07 08:58:50.243 +
>> >>
>> >> ```
>> >>
>> >> When I look at the callstacks (at the top level), I see this:
>> >>
>> >> ```
>> >>
>> >> "Pooled Waiting Message Processor 1" #213 daemon prio=5 os_prio=0
>> >> tid=0x7fc738024000 nid=0x488 waiting for monitor entry
>> >> [0x7fc7ec5f7000]
>> >>
>> >> java.lang.Thread.State: BLOCKED (on object monitor)
>> >>
>> >>  at
>> >>
>> org.apache.geode.distributed.internal.membership.adapter.GMSMembershipManager.startEventProcessing(GMSMembershipManager.java:1179)
>> >>
>> >>  - waiting to lock <0xe03a75e0> (a java.lang.Object)
>> >>
>> >>  at
>> >>
>> org.apache.geode.distributed.internal.ClusterDistributionManager.readyForMessages(ClusterDistributionManager.java:1152)
>> >>
>> >>  at
>> >>
>> org.apache.geode.distributed.internal.ClusterDistributionManager.lambda$startThreads$10(ClusterDistributionManager.java:1129)
>> >>
>> >>  at
>> >>
>> org.apache.geode.distributed.internal.ClusterDistributionManager$$Lambda$87/1408912936.run(Unknown
>> >> Source)
>> >>
>> >>  at
>> >>
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>> >>
>> >>  at
>> >>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>> >>
>> >>  at
>> >>
>> 

Re: geode-native ipv6

[Blake Bender]

I'm sure someone will chime in with a more definitive answer, but I'm
pretty certain the answer is no, sorry.

Thanks,

Blake


On Thu, Aug 8, 2019 at 4:28 AM Mario Ivanac  wrote:

> Hi,
>
>
> can you tell me does geode-native client support ipv6?
>
>
> BR,
>
> Mario
>

geode-native ipv6

[Mario Ivanac]

Hi,


can you tell me does geode-native client support ipv6?


BR,

Mario

Re: Reviewers for PR

[Mario Ivanac]

Hi,


could someone review PR https://github.com/apache/geode/pull/3854.


Thanks


Šalje: Mark Hanson 
Poslano: 6. kolovoza 2019. 19:21:42
Prima: dev@geode.apache.org 
Predmet: Reviewers for PR

Hi All,

Here is another PR that could use reviewers.

GEODE-6748: First part of solution #3854 
https://github.com/apache/geode/pull/3854 


Thanks,
Mark