Odg: Restart gateway-receiver

[Mario Kevo]

Hi,

@Barry Oglesby, thanks for the clarification.

If we don't send any event, the connection will be closed after some time as 
connection is inactive.
Is it possible to somehow monitor from the app if the replication is 
established to get information if there is a some problem with network or it is 
just closed due to inactivity?
Can we monitor the replication on some other way than looking "isConnected" 
state on JMX?

BR,
Mario

Šalje: Barry Oglesby 
Poslano: 14. studenog 2019. 18:29
Prima: dev@geode.apache.org 
Predmet: Re: Restart gateway-receiver

Mario,

Thats the current behavior. When the sender is initially started, it
attempts to connect to the receiver. If it does not connect, it won't retry
until there is a batch of events to send. Look for callers of
GatewaySenderEventRemoteDispatcher.initializeConnection to see the
behavior. It could be changed to have a task to retry lost connections, but
generally there are events in the queue, so the connection is
re-established pretty quickly by the event processor thread.

Thanks,
Barry Oglesby



On Wed, Nov 13, 2019 at 4:55 AM Mario Kevo  wrote:

> Hi geode dev,
>
> After creating gateways senders and receivers between two geode clusters
> replications is established. After restart gateway receiver, sender will
> not connect to it until we send some entry from sender to receiver.
> Is this a normal behavior or a bug?
> Should geode have some mechanism for checking if connection is established
> no matter if entry is sent or not?
>
> BR,
> Mario
>

Passed: apache/geode-native#2224 (develop - d3a185b)

[Travis CI]

Build Update for apache/geode-native
-

Build: #2224
Status: Passed

Duration: 1 hr, 33 mins, and 23 secs
Commit: d3a185b (develop)
Author: Alberto Gomez
Message: GEODE-7476: Fix several leaks in native client (#553)

* Fixed most leaks found when running the new integration
tests under valgrind.

View the changeset: 
https://github.com/apache/geode-native/compare/13caf576e6b0...d3a185b8b326

View the full build log and details: 
https://travis-ci.org/apache/geode-native/builds/615266318?utm_medium=notification_source=email

--

You can unsubscribe from build emails from the apache/geode-native repository 
going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=11948127_medium=notification_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Re: [VOTE] Apache Geode 1.11.0.RC2

[Mark Hanson]

Agreed. 


> On Nov 21, 2019, at 11:38 AM, Dan Smith  wrote:
> 
> -1 based on Blakes feedback. If we need to change the native client tag and
> source zip, we need to create RC3.
> 
> -Dan
> 
> On Thu, Nov 21, 2019 at 11:31 AM Blake Bender  wrote:
> 
>> We could also just tag the current NC develop branch.  I've run all my
>> integration tests from NC develop branch against 1.11.0.RC2, and it looks
>> good on Mac, Windows and Linux.
>> 
>> 
>> On Thu, Nov 21, 2019 at 11:25 AM Blake Bender  wrote:
>> 
>>> If it's a requirement that the native client runs properly, I'm a -1.
>>> There's a segfault bug in NC logging (see
>>> https://github.com/apache/geode-native/pull/545), and the release tag is
>>> prior to the fix.  I'd prefer to pick up NC from this commit:
>>> 
>> https://github.com/apache/geode-native/commit/c932a1d765809dcd8d7a0c0f14a3aa6c98e18a5c
>>> .
>>> 
>>> Thanks,
>>> 
>>> Blake
>>> 
>>> 
>>> On Wed, Nov 20, 2019 at 5:16 PM Mark Hanson  wrote:
>>> 
 Hello Geode Dev Community,
 
 This is a release candidate for Apache Geode version 1.11.0.RC2.
 Thanks to all the community members for their contributions to this
 release!
 
 Please do a review and give your feedback, including the checks you
 performed.
 
 Voting deadline:
 3PM PST Mon, November 25 2019.
 
 Please note that we are voting upon the source tag:
 rel/v1.11.0.RC2
 
 Release notes:
 
 
>> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.11.0
 
 Source and binary distributions:
 https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC2/
 
 Maven staging repo:
 https://repository.apache.org/content/repositories/orgapachegeode-1062
 
 GitHub:
 https://github.com/apache/geode/tree/rel/v1.11.0.RC2
 https://github.com/apache/geode-examples/tree/rel/v1.11.0.RC2
 https://github.com/apache/geode-native/tree/rel/v1.11.0.RC2
 
 Pipelines:
 
 
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-main
 
 
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-rc
 
 Geode's KEYS file containing PGP keys we use to sign the release:
 https://github.com/apache/geode/blob/develop/KEYS
 
 Command to run geode-examples:
 ./gradlew -PgeodeReleaseUrl=
 https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC2
 -PgeodeRepositoryUrl=
 https://repository.apache.org/content/repositories/orgapachegeode-1062
 build runAll
 
 
 
>> 

Re: DistributionArchUnitTest OutOfMemoryError

[Dan Smith]

We've disabled this test for now, so you shouldn't get an OOME with the
latest develop.

-Dan

On Wed, Nov 20, 2019, 4:55 PM Michael Oleske  wrote:

> I've hit the same error as Kirk.  My lazy solution was to just rerun
> `./gradlew build` cause that would pass on the second time.
>
> -michael
>
> On Wed, Nov 20, 2019 at 4:53 PM Dan Smith  wrote:
>
> > We recently added this test. It passes for me, but I will look into it.
> It
> > is scanning classes, so that may be your oome.
> >
> > On Wed, Nov 20, 2019, 4:00 PM Kirk Lund  wrote:
> >
> > > Any ideas why DistributionArchUnitTest would run OutOfMemoryError when
> > > doing a "./gradlew build"?
> > >
> > > I think we should move any unit tests that run OutOfMemoryError out of
> > unit
> > > tests (to integration tests maybe?).
> > >
> > > > Task :geode:geode-core:test
> > > Heap dump file created [957877145 bytes in 17.227 secs]
> > >
> > > org.apache.geode.distributed.internal.DistributionArchUnitTest >
> > > classMethod FAILED
> > > java.lang.OutOfMemoryError: GC overhead limit exceeded
> > >
> > > 6991 tests completed, 1 failed, 12 skipped
> > >
> >
>

Re: [VOTE] Apache Geode 1.11.0.RC2

[Dan Smith]

-1 based on Blakes feedback. If we need to change the native client tag and
source zip, we need to create RC3.

-Dan

On Thu, Nov 21, 2019 at 11:31 AM Blake Bender  wrote:

> We could also just tag the current NC develop branch.  I've run all my
> integration tests from NC develop branch against 1.11.0.RC2, and it looks
> good on Mac, Windows and Linux.
>
>
> On Thu, Nov 21, 2019 at 11:25 AM Blake Bender  wrote:
>
> > If it's a requirement that the native client runs properly, I'm a -1.
> > There's a segfault bug in NC logging (see
> > https://github.com/apache/geode-native/pull/545), and the release tag is
> > prior to the fix.  I'd prefer to pick up NC from this commit:
> >
> https://github.com/apache/geode-native/commit/c932a1d765809dcd8d7a0c0f14a3aa6c98e18a5c
> > .
> >
> > Thanks,
> >
> > Blake
> >
> >
> > On Wed, Nov 20, 2019 at 5:16 PM Mark Hanson  wrote:
> >
> >> Hello Geode Dev Community,
> >>
> >> This is a release candidate for Apache Geode version 1.11.0.RC2.
> >> Thanks to all the community members for their contributions to this
> >> release!
> >>
> >> Please do a review and give your feedback, including the checks you
> >> performed.
> >>
> >> Voting deadline:
> >> 3PM PST Mon, November 25 2019.
> >>
> >> Please note that we are voting upon the source tag:
> >> rel/v1.11.0.RC2
> >>
> >> Release notes:
> >>
> >>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.11.0
> >>
> >> Source and binary distributions:
> >> https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC2/
> >>
> >> Maven staging repo:
> >> https://repository.apache.org/content/repositories/orgapachegeode-1062
> >>
> >> GitHub:
> >> https://github.com/apache/geode/tree/rel/v1.11.0.RC2
> >> https://github.com/apache/geode-examples/tree/rel/v1.11.0.RC2
> >> https://github.com/apache/geode-native/tree/rel/v1.11.0.RC2
> >>
> >> Pipelines:
> >>
> >>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-main
> >>
> >>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-rc
> >>
> >> Geode's KEYS file containing PGP keys we use to sign the release:
> >> https://github.com/apache/geode/blob/develop/KEYS
> >>
> >> Command to run geode-examples:
> >> ./gradlew -PgeodeReleaseUrl=
> >> https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC2
> >> -PgeodeRepositoryUrl=
> >> https://repository.apache.org/content/repositories/orgapachegeode-1062
> >> build runAll
> >>
> >>
> >>
>

Re: [VOTE] Apache Geode 1.11.0.RC2

[Blake Bender]

We could also just tag the current NC develop branch.  I've run all my
integration tests from NC develop branch against 1.11.0.RC2, and it looks
good on Mac, Windows and Linux.


On Thu, Nov 21, 2019 at 11:25 AM Blake Bender  wrote:

> If it's a requirement that the native client runs properly, I'm a -1.
> There's a segfault bug in NC logging (see
> https://github.com/apache/geode-native/pull/545), and the release tag is
> prior to the fix.  I'd prefer to pick up NC from this commit:
> https://github.com/apache/geode-native/commit/c932a1d765809dcd8d7a0c0f14a3aa6c98e18a5c
> .
>
> Thanks,
>
> Blake
>
>
> On Wed, Nov 20, 2019 at 5:16 PM Mark Hanson  wrote:
>
>> Hello Geode Dev Community,
>>
>> This is a release candidate for Apache Geode version 1.11.0.RC2.
>> Thanks to all the community members for their contributions to this
>> release!
>>
>> Please do a review and give your feedback, including the checks you
>> performed.
>>
>> Voting deadline:
>> 3PM PST Mon, November 25 2019.
>>
>> Please note that we are voting upon the source tag:
>> rel/v1.11.0.RC2
>>
>> Release notes:
>>
>> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.11.0
>>
>> Source and binary distributions:
>> https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC2/
>>
>> Maven staging repo:
>> https://repository.apache.org/content/repositories/orgapachegeode-1062
>>
>> GitHub:
>> https://github.com/apache/geode/tree/rel/v1.11.0.RC2
>> https://github.com/apache/geode-examples/tree/rel/v1.11.0.RC2
>> https://github.com/apache/geode-native/tree/rel/v1.11.0.RC2
>>
>> Pipelines:
>>
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-main
>>
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-rc
>>
>> Geode's KEYS file containing PGP keys we use to sign the release:
>> https://github.com/apache/geode/blob/develop/KEYS
>>
>> Command to run geode-examples:
>> ./gradlew -PgeodeReleaseUrl=
>> https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC2
>> -PgeodeRepositoryUrl=
>> https://repository.apache.org/content/repositories/orgapachegeode-1062
>> build runAll
>>
>>
>>

Re: [VOTE] Apache Geode 1.11.0.RC2

[Blake Bender]

If it's a requirement that the native client runs properly, I'm a -1.
There's a segfault bug in NC logging (see
https://github.com/apache/geode-native/pull/545), and the release tag is
prior to the fix.  I'd prefer to pick up NC from this commit:
https://github.com/apache/geode-native/commit/c932a1d765809dcd8d7a0c0f14a3aa6c98e18a5c
.

Thanks,

Blake


On Wed, Nov 20, 2019 at 5:16 PM Mark Hanson  wrote:

> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.11.0.RC2.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline:
> 3PM PST Mon, November 25 2019.
>
> Please note that we are voting upon the source tag:
> rel/v1.11.0.RC2
>
> Release notes:
>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.11.0
>
> Source and binary distributions:
> https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC2/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachegeode-1062
>
> GitHub:
> https://github.com/apache/geode/tree/rel/v1.11.0.RC2
> https://github.com/apache/geode-examples/tree/rel/v1.11.0.RC2
> https://github.com/apache/geode-native/tree/rel/v1.11.0.RC2
>
> Pipelines:
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-main
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-rc
>
> Geode's KEYS file containing PGP keys we use to sign the release:
> https://github.com/apache/geode/blob/develop/KEYS
>
> Command to run geode-examples:
> ./gradlew -PgeodeReleaseUrl=
> https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC2
> -PgeodeRepositoryUrl=
> https://repository.apache.org/content/repositories/orgapachegeode-1062
> build runAll
>
>
>

Re: Access to edit the Geode Wiki

[Dan Smith]

Hi Mark,

You should have access now.

Thanks,
-Dan

On Wed, Nov 20, 2019 at 5:27 PM Mark Hanson  wrote:

> Hi All,
>
> Can I have access to edit the Geode Wiki to add release notes? My
> confluence ID is "mhanson".
>
> Thanks,
> Mark

Odg: Proposal of new config property "ssl-server-name-extension"

[Mario Ivanac]

Hi,

regarding your questions:

>>Mario, are there any limitations that should be understood about the types
of certificates used or how they're generated?<<

There is no limitations.


>>Do you have the freedom to use certificate chaining and have the root CA in 
>>each component's
truststore?<<

Yes

BR,
Mario


Šalje: Ivan Godwin 
Poslano: 21. studenog 2019. 4:29
Prima: dev@geode.apache.org 
Predmet: Re: Proposal of new config property "ssl-server-name-extension"

Thank you for the reference to the other thread, Jens. I hope my questions
aren't too late in the process.

Mario, are there any limitations that should be understood about the types
of certificates used or how they're generated? Do you have the freedom to
use certificate chaining and have the root CA in each component's
truststore? Dan's concern of a future, valid use case resonates quite a bit
with me.

Ivan


On Wed, Nov 20, 2019, 18:43 Jens Deppe  wrote:

> This thread contains more background on the reasons for this proposal:
>
> https://lists.apache.org/thread.html/2418dd1b5f9ae812daa48a51a8d2eb252a3c861a890264f47da3a4d3@%3Cdev.geode.apache.org%3E
>
> On Wed, Nov 20, 2019 at 10:46 AM Ivan Godwin  wrote:
>
> > I've reviewed the PR and I believe I understand the use case, but I feel
> a
> > bit uncomfortable with the misuse of SNI. As I understand it, and as it
> has
> > been already mentioned, SNI is used to determine which SSL certificate
> > should be presented to a client.
> >
> > I think that CLIENT_HELLO_EXTENSION should *not* be associated with SSL,
> > and that a new client property should be used instead. That is, a
> different
> > property, unrelated to SSL, should be used to set what will be verified
> > against CLIENT_HELLO_EXTENSION.
> >
> > On Tue, Nov 19, 2019 at 4:43 PM Jens Deppe  wrote:
> >
> > > I'd like to add my comment from the original PR here again:
> > >
> > >
> > > Although I support the particular use case, I would prefer the
> > > implementation being a bit more abstracted. Specifically, if we
> provided
> > an
> > > extension point which would allow modification of SSLParameters then we
> > > wouldn't be coupling to a particular use case. So I'm thinking that the
> > > user would define (via say a ssl-parameter-extension parameter) a class
> > > that takes in a SSLParameter and perhaps SSLConfig and whatever else
> for
> > > this use-case and does what it needs. The user class would need to
> > > implement an interface something like this:
> > >
> > > public interface SSLParameterExtension {
> > >   SSLParameter modify(SSLParameter, SSLConfig);
> > > }
> > >
> > > I would imagine seeing the user implementation of this being attached
> to
> > > SSLConfig.
> > >
> > >
> > > (https://github.com/apache/geode/pull/4310)
> > >
> > > I don't mind (mis)using the Server Name field to convey some other
> > > information, but since it's possible to abstract the specific nature
> and
> > > application of that information, I think we should do so. Anyone else
> who
> > > looks at the code is going to wonder what the use is especially if the
> > > consumer of that particular piece of info is going to be provided via
> an
> > > external SSLEngine implementation.
> > >
> > > --Jens
> > >
> > > On Tue, Nov 19, 2019 at 1:18 PM Dan Smith  wrote:
> > >
> > > > Can you clarify which connections will use this
> > ssl-server-name-extension
> > > > as part of the Client Hello? client to locator, client to server,
> > server
> > > to
> > > > server, WAN site to WAN site, ... all of the above?
> > > >
> > > > I'm fine with adding the new property.
> > > >
> > > > At some point, I think we need to think about making it easier to
> plug
> > in
> > > > custom logic to control the entire socket creation and TLS
> handshake. I
> > > > think technically you can take over the whole process if you set the
> > > > ssl-use-default-context property and then configure the default
> > > SSLContext
> > > > for your entire process, but that is not ideal.
> > > >
> > > > -Dan
> > > >
> > > > On Tue, Nov 19, 2019 at 8:24 AM Charlie Black 
> > wrote:
> > > >
> > > > > I have read the e-mail and the ticket I am not sure how this field
> is
> > > > going
> > > > > to be used.   Maybe you can expand on the intent of this field.
> > > > >
> > > > > From the property "ssl-server-name-extension" it feels like we are
> > > > > intending to correlate with something presented in the SSL
> > certificate.
> > > > > It would be great if that was explained plainly for the reader in
> > more
> > > > > detail.
> > > > >
> > > > > For now I can only -1.
> > > > >
> > > > > Charlie
> > > > >
> > > > > On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac  >
> > > > > wrote:
> > > > >
> > > > > > Hi geode dev,
> > > > > >
> > > > > > as a part of solution for
> > > > > https://issues.apache.org/jira/browse/GEODE-7414
> > > > > > we would like to introduce new config property
> > > > > "ssl-server-name-extension".
> > > > > >

Odg: Proposal of new config property "ssl-server-name-extension"

[Mario Ivanac]

Hi,

all connections will use ssl-server-name-extension as part of Client Hello.

BR,
Mario

Šalje: Dan Smith 
Poslano: 19. studenog 2019. 22:17
Prima: dev@geode.apache.org 
Predmet: Re: Proposal of new config property "ssl-server-name-extension"

Can you clarify which connections will use this ssl-server-name-extension
as part of the Client Hello? client to locator, client to server, server to
server, WAN site to WAN site, ... all of the above?

I'm fine with adding the new property.

At some point, I think we need to think about making it easier to plug in
custom logic to control the entire socket creation and TLS handshake. I
think technically you can take over the whole process if you set the
ssl-use-default-context property and then configure the default SSLContext
for your entire process, but that is not ideal.

-Dan

On Tue, Nov 19, 2019 at 8:24 AM Charlie Black  wrote:

> I have read the e-mail and the ticket I am not sure how this field is going
> to be used.   Maybe you can expand on the intent of this field.
>
> From the property "ssl-server-name-extension" it feels like we are
> intending to correlate with something presented in the SSL certificate.
> It would be great if that was explained plainly for the reader in more
> detail.
>
> For now I can only -1.
>
> Charlie
>
> On Tue, Nov 19, 2019 at 3:27 AM Mario Ivanac 
> wrote:
>
> > Hi geode dev,
> >
> > as a part of solution for
> https://issues.apache.org/jira/browse/GEODE-7414
> > we would like to introduce new config property
> "ssl-server-name-extension".
> >
> > This property will contain generic string, which will be added as Server
> > Name Indication (SNI) parameter to Client Hello message.
> >
> > Do you agree with this proposal?
> >
> > Thanks,
> > Mario
> >
>
>
> --
> Charlie Black | cbl...@pivotal.io
>