Re: [ANNOUNCE] New Geode Committer - Kamilla Aslami

[Nabarun Nag]

Congrats Kamila!! Welcome!!!

From: Donal Evans 
Sent: Monday, April 19, 2021 2:48 PM
To: dev@geode.apache.org 
Subject: Re: [ANNOUNCE] New Geode Committer - Kamilla Aslami

Congrats Kamilla!

From: Mark Hanson 
Sent: Monday, April 19, 2021 2:37 PM
To: dev@geode.apache.org 
Subject: Re: [ANNOUNCE] New Geode Committer - Kamilla Aslami

Congratulations Kamilla!

On 4/19/21, 2:33 PM, "Sarah Abbey"  wrote:

Congratulations, Kamilla!!!

From: Ernie Burghardt 
Sent: Monday, April 19, 2021 5:22 PM
To: dev@geode.apache.org 
Subject: [ANNOUNCE] New Geode Committer - Kamilla Aslami

The Apache Geode Project Management Committee has invited Kamilla Aslami to 
join the Geode as a Committer and we are pleased to announce she has
accepted.

Please join me in welcoming Kamilla!

Best regards,
EB
On behalf of the Apache Geode PMC

Re: [ANNOUNCE] New Geode Committer - Kamilla Aslami

[Donal Evans]

Congrats Kamilla!

From: Mark Hanson 
Sent: Monday, April 19, 2021 2:37 PM
To: dev@geode.apache.org 
Subject: Re: [ANNOUNCE] New Geode Committer - Kamilla Aslami

Congratulations Kamilla!

On 4/19/21, 2:33 PM, "Sarah Abbey"  wrote:

Congratulations, Kamilla!!!

From: Ernie Burghardt 
Sent: Monday, April 19, 2021 5:22 PM
To: dev@geode.apache.org 
Subject: [ANNOUNCE] New Geode Committer - Kamilla Aslami

The Apache Geode Project Management Committee has invited Kamilla Aslami to 
join the Geode as a Committer and we are pleased to announce she has
accepted.

Please join me in welcoming Kamilla!

Best regards,
EB
On behalf of the Apache Geode PMC

Re: [ANNOUNCE] New Geode Committer - Kamilla Aslami

[Mark Hanson]

Congratulations Kamilla!

On 4/19/21, 2:33 PM, "Sarah Abbey"  wrote:

Congratulations, Kamilla!!!

From: Ernie Burghardt 
Sent: Monday, April 19, 2021 5:22 PM
To: dev@geode.apache.org 
Subject: [ANNOUNCE] New Geode Committer - Kamilla Aslami

The Apache Geode Project Management Committee has invited Kamilla Aslami to 
join the Geode as a Committer and we are pleased to announce she has
accepted.

Please join me in welcoming Kamilla!

Best regards,
EB
On behalf of the Apache Geode PMC

Re: [ANNOUNCE] New Geode Committer - Kamilla Aslami

[Sarah Abbey]

Congratulations, Kamilla!!!

From: Ernie Burghardt 
Sent: Monday, April 19, 2021 5:22 PM
To: dev@geode.apache.org 
Subject: [ANNOUNCE] New Geode Committer - Kamilla Aslami

The Apache Geode Project Management Committee has invited Kamilla Aslami to 
join the Geode as a Committer and we are pleased to announce she has
accepted.

Please join me in welcoming Kamilla!

Best regards,
EB
On behalf of the Apache Geode PMC

[ANNOUNCE] New Geode Committer - Kamilla Aslami

[Ernie Burghardt]

The Apache Geode Project Management Committee has invited Kamilla Aslami to 
join the Geode as a Committer and we are pleased to announce she has
accepted.

Please join me in welcoming Kamilla!

Best regards,
EB
On behalf of the Apache Geode PMC

Re: Geode retry/acknowledge improvement

[Anthony Baker]

Do you have a tcpdump that demonstrates the packet loss? How long did you wait 
for TCP to retry the failed packet delivery (sometimes this can be tweaked with 
tcp_retries2).  Does this manifest as a failed socket connection in geode?  
That ought to trigger some error handling IIRC.

Anthony


> On Apr 19, 2021, at 7:16 AM, Mario Ivanac  wrote:
> 
> Hi all,
> 
> we have deployed geode cluster in kubernetes environment, and Istio/SideCars 
> are injected between cluster members.
> While running traffic, if any Istio/SideCar is restarted, thread will get 
> stuck indefinitely, while waiting for reply on sent message.
> It seams that due to restarting of proxy, in some cases, messages are lost, 
> and sending side is waiting indefinitely for reply.
> 
> https://issues.apache.org/jira/browse/GEODE-9075
> 
> My question is, what is your estimation, how much effort/work is needed to 
> implement message retry/acknowledge logic in geode,
> to solve this problem?
> 
> BR,
> Mario

Re: [VOTE] Requiring final keyword on every parameter and local variable

[Owen Nichols]

Any interest in adopting https://projectlombok.org in Geode?  Lombok allow a 
more readable "val" vs "var" syntax instead of "final" vs "" which could make 
it easier to do the right thing without "increasing visual noise".

On 4/19/21, 12:40 PM, "Dale Emery"  wrote:

My test for whether enforce a guideline in a PR review is: Would I be 
willing to automate enforcing it in CI?

I am -0 on this particular guideline.

IntelliJ offers two competing inspections for Java coding style:

  *   Local variable or parameter can be final
  *   Unnecessary 'final' on local variable or parameter

Both of these are (I think) disabled by default in IntelliJ. And neither 
satisfies my “I’d be willing to automate enforcing it” test.

Dale

From: Mark Hanson 
Date: Monday, April 19, 2021 at 11:08 AM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Requiring final keyword on every parameter and local 
variable
Hi Jake,

I agree with everyone's point about final being a useful, I just don't find 
it useful enough to do anything manually across the code base at this point.

I believe first in foremost in no code warnings. Intellij warns about 
variables that can be final, so I make them final as it finds them. It is very 
rare that I am writing new code at this point. I have spent the last year bug 
fixing other people's code.  From my standpoint, original intent is largely 
moot. So, for me, the question is do I go through code that is not mine and 
mark it all as final (where appropriate)? Sure, in code that I touch. In code 
the rest of the codebase, I think there are bigger fish to fry before we get to 
final.

It seems like the larger portion of the consensus is to recommend that 
variables are marked final (where appropriate) as we find them or create them.
That seems like the going forward approach consensus.

I will be blunt though. This seems nitpicky *compared* to the number of 
code warnings there are and the fact that people are not actively fixing all of 
the warnings.
If we don't come to the same consensus about all warnings this seems like 
painting a rusted car, sure it makes it all look the same, but does very little 
for the underlying problems. Now to undermine my own argument a little, I think 
that especially in release blockers, we want to touch as little code as 
possible, so I am flexible there.

I would also like to agree with Udo about final really not being very good 
compared to Mutable and Immutable objects in other languages.

Thanks,
Mark


On 4/15/21, 7:49 PM, "Udo Kohlmeyer"  wrote:

@jake, you are correct, I did miss the LOCAL variable out of the 
subject. :face_palm:

Yes, adding "final" to LOCAL variables will be HUGELY beneficial in 
this regard. Have we seen any performance improvement after having refactored 
this method? Have you been able to measure any improvements?

--Udo

On 4/15/21, 1:19 PM, "Jacob Barrett"  wrote:



> On Apr 14, 2021, at 7:46 PM, Udo Kohlmeyer  
wrote:
> @Jake the idea of smaller methods is great and we should ALWAYS 
strive for that. But that argument is completely irrelevant in this discussion. 
As making method arguments final does not naturally guide a developer to 
creating smaller methods. Nor does a smaller method mean it can/will be jitted. 
Too many factors (to discuss here) are part of that decision, also it is not 
relevant in this discussion. But more on that topic read THIS.

The original subject is in regards to parameters and local 
variables.

Irrelevant is certainly an opinion you are welcome to have but let 
me challenge you. Goto DistributedCacheOperation._distribute().

First challenge, look at around line 333:
boolean reliableOp = isOperationReliable() && 
region.requiresReliabilityCheck();

Without scrolling do you see that variable used? Nope, because it 
is first used on line 439, ~100 lines away. Does it mutate between there, well 
I can search for all uses and find out or I could be nice to the next person 
and intend for it to never mutate by adding final. Intent communicated!

Second challenge, mark all the local variables in the method as 
final. Now make it compile without introducing more mutable variables. At the 
end of this journey you will have about a dozen unit testable methods and a 
_distribute method that goes from ~370 lines to  ~90 with no mutable local 
variables.

I argue it is relevant as good guardrail for writing good code. 
While we should ALWAYS strive for it we don’t. Every little nudge helps.


-Jake

Re: [VOTE] Requiring final keyword on every parameter and local variable

[Dale Emery]

My test for whether enforce a guideline in a PR review is: Would I be willing 
to automate enforcing it in CI?

I am -0 on this particular guideline.

IntelliJ offers two competing inspections for Java coding style:

  *   Local variable or parameter can be final
  *   Unnecessary 'final' on local variable or parameter

Both of these are (I think) disabled by default in IntelliJ. And neither 
satisfies my “I’d be willing to automate enforcing it” test.

Dale

From: Mark Hanson 
Date: Monday, April 19, 2021 at 11:08 AM
To: dev@geode.apache.org 
Subject: Re: [VOTE] Requiring final keyword on every parameter and local 
variable
Hi Jake,

I agree with everyone's point about final being a useful, I just don't find it 
useful enough to do anything manually across the code base at this point.

I believe first in foremost in no code warnings. Intellij warns about variables 
that can be final, so I make them final as it finds them. It is very rare that 
I am writing new code at this point. I have spent the last year bug fixing 
other people's code.  From my standpoint, original intent is largely moot. So, 
for me, the question is do I go through code that is not mine and mark it all 
as final (where appropriate)? Sure, in code that I touch. In code the rest of 
the codebase, I think there are bigger fish to fry before we get to final.

It seems like the larger portion of the consensus is to recommend that 
variables are marked final (where appropriate) as we find them or create them.
That seems like the going forward approach consensus.

I will be blunt though. This seems nitpicky *compared* to the number of code 
warnings there are and the fact that people are not actively fixing all of the 
warnings.
If we don't come to the same consensus about all warnings this seems like 
painting a rusted car, sure it makes it all look the same, but does very little 
for the underlying problems. Now to undermine my own argument a little, I think 
that especially in release blockers, we want to touch as little code as 
possible, so I am flexible there.

I would also like to agree with Udo about final really not being very good 
compared to Mutable and Immutable objects in other languages.

Thanks,
Mark


On 4/15/21, 7:49 PM, "Udo Kohlmeyer"  wrote:

@jake, you are correct, I did miss the LOCAL variable out of the subject. 
:face_palm:

Yes, adding "final" to LOCAL variables will be HUGELY beneficial in this 
regard. Have we seen any performance improvement after having refactored this 
method? Have you been able to measure any improvements?

--Udo

On 4/15/21, 1:19 PM, "Jacob Barrett"  wrote:



> On Apr 14, 2021, at 7:46 PM, Udo Kohlmeyer  wrote:
> @Jake the idea of smaller methods is great and we should ALWAYS 
strive for that. But that argument is completely irrelevant in this discussion. 
As making method arguments final does not naturally guide a developer to 
creating smaller methods. Nor does a smaller method mean it can/will be jitted. 
Too many factors (to discuss here) are part of that decision, also it is not 
relevant in this discussion. But more on that topic read THIS.

The original subject is in regards to parameters and local variables.

Irrelevant is certainly an opinion you are welcome to have but let me 
challenge you. Goto DistributedCacheOperation._distribute().

First challenge, look at around line 333:
boolean reliableOp = isOperationReliable() && 
region.requiresReliabilityCheck();

Without scrolling do you see that variable used? Nope, because it is 
first used on line 439, ~100 lines away. Does it mutate between there, well I 
can search for all uses and find out or I could be nice to the next person and 
intend for it to never mutate by adding final. Intent communicated!

Second challenge, mark all the local variables in the method as final. 
Now make it compile without introducing more mutable variables. At the end of 
this journey you will have about a dozen unit testable methods and a 
_distribute method that goes from ~370 lines to  ~90 with no mutable local 
variables.

I argue it is relevant as good guardrail for writing good code. While 
we should ALWAYS strive for it we don’t. Every little nudge helps.


-Jake

Re: [DISCUSS] Monthly, synchronous community meetings

[Alexander Murmann]

Since there are only voices in support of this, I propose that we hold our 
meeting on the first Wednesday of the month. This means our first meeting will 
be May 5th.

I set up a doc for meeting notes, agenda and logistics in our wiki: 
https://cwiki.apache.org/confluence/x/upaNCg

I believe that everyone in the community should be able to use MS Teams. I set 
up a VMware sponsored MS Teams event for this. Always happy to iterate, if 
there are ideas for a different platform that feels more aligned with OSS and 
Apache.

I suggest everyone adds their topics as early as possible, to make sure folks 
can decide if they are going to make to make sure to attend if one of the 
topics seems very relevant to them

See you all on May 5th at 3pm/15:00 UTC (11amEDT/8amPST/17:00 CEST)



From: Dan Smith 
Sent: Monday, April 12, 2021 09:39
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Monthly, synchronous community meetings

Seems like a good idea. I have no preference on video conference platform.

-Dan

From: Alberto Gomez 
Sent: Friday, April 9, 2021 1:25 AM
To: dev@geode.apache.org 
Subject: Re: [DISCUSS] Monthly, synchronous community meetings

Hi,

This idea sounds great to me.

Have you thought about the videoconference platform to host these meetings?

Best regards,

Alberto

From: Alexander Murmann 
Sent: Friday, April 9, 2021 2:46 AM
To: dev@geode.apache.org 
Subject: [DISCUSS] Monthly, synchronous community meetings

Hi everyone,

On occasion we see discussions on PRs, here on the mailing list that might be 
move much quicker if we chatted synchronously about some of these topics and 
then shared the meetings notes back to the mailing list. Of course, our usual 
processes for voting and additional discussions would still need to be just as 
accessible as they are right now on the mailing list to anyone who cannot 
attend a meeting. However, it might allow us to move these discussions along 
faster and also create a stronger sense of community.

I've seen similar things done in Kubernetes Special Interest Groups 
(example)

Meeting Specifics
Frequency: monthly
Time: It seems like most of our community is distributed between Europe and the 
US. 3pm/15:00 UTC (11amEDT/8amPST/17:00 CEST) seems like a good compromise.
How: We'd have a Confluence page to gather topics ahead of time. Topics should 
be added with as much lead time as possible, to allow interested community 
members to plan attendance. We'd use the same page to take meeting notes.
Topic examples: RFC discussions, process proposals (like the recent codeowner 
introduction), show & tells of recent changes, controversial PRs, the sky is 
the limit till we find certain topics are better in a dedicated meeting.

As with everything, I'd expect us to iterate and evolve this

Does this sound valuable to everyone? How could this be better?

Re: [VOTE] Requiring final keyword on every parameter and local variable

[Mark Hanson]

Does everyone feel that adding final here is the best thing to do? If not, then 
"Always" becomes "Strongly Encouraged where appropriate"

  protected void validateUDPEncryptionStats() {
long encrptTime = 
getGemfireCache().getDistributionManager().getStats().getUDPMsgEncryptionTime();
long decryptTime = 
getGemfireCache().getDistributionManager().getStats().getUDPMsgDecryptionTime();
assertTrue("Should have multicast writes or reads. encrptTime=  " + 
encrptTime
+ " ,decryptTime= " + decryptTime, encrptTime == 0 && decryptTime == 0);
  }

Note: the code actually warns about getGemfireCache() being deprecated. 

Thanks,
Mark

On 4/19/21, 11:08 AM, "Mark Hanson"  wrote:

Hi Jake,

I agree with everyone's point about final being a useful, I just don't find 
it useful enough to do anything manually across the code base at this point.

I believe first in foremost in no code warnings. Intellij warns about 
variables that can be final, so I make them final as it finds them. It is very 
rare that I am writing new code at this point. I have spent the last year bug 
fixing other people's code.  From my standpoint, original intent is largely 
moot. So, for me, the question is do I go through code that is not mine and 
mark it all as final (where appropriate)? Sure, in code that I touch. In code 
the rest of the codebase, I think there are bigger fish to fry before we get to 
final.

It seems like the larger portion of the consensus is to recommend that 
variables are marked final (where appropriate) as we find them or create them. 
That seems like the going forward approach consensus.

I will be blunt though. This seems nitpicky *compared* to the number of 
code warnings there are and the fact that people are not actively fixing all of 
the warnings.
If we don't come to the same consensus about all warnings this seems like 
painting a rusted car, sure it makes it all look the same, but does very little 
for the underlying problems. Now to undermine my own argument a little, I think 
that especially in release blockers, we want to touch as little code as 
possible, so I am flexible there.

I would also like to agree with Udo about final really not being very good 
compared to Mutable and Immutable objects in other languages.

Thanks,
Mark


On 4/15/21, 7:49 PM, "Udo Kohlmeyer"  wrote:

@jake, you are correct, I did miss the LOCAL variable out of the 
subject. :face_palm:

Yes, adding "final" to LOCAL variables will be HUGELY beneficial in 
this regard. Have we seen any performance improvement after having refactored 
this method? Have you been able to measure any improvements?

--Udo 

On 4/15/21, 1:19 PM, "Jacob Barrett"  wrote:



> On Apr 14, 2021, at 7:46 PM, Udo Kohlmeyer  
wrote:
> @Jake the idea of smaller methods is great and we should ALWAYS 
strive for that. But that argument is completely irrelevant in this discussion. 
As making method arguments final does not naturally guide a developer to 
creating smaller methods. Nor does a smaller method mean it can/will be jitted. 
Too many factors (to discuss here) are part of that decision, also it is not 
relevant in this discussion. But more on that topic read THIS.

The original subject is in regards to parameters and local 
variables.

Irrelevant is certainly an opinion you are welcome to have but let 
me challenge you. Goto DistributedCacheOperation._distribute(). 

First challenge, look at around line 333: 
boolean reliableOp = isOperationReliable() && 
region.requiresReliabilityCheck();

Without scrolling do you see that variable used? Nope, because it 
is first used on line 439, ~100 lines away. Does it mutate between there, well 
I can search for all uses and find out or I could be nice to the next person 
and intend for it to never mutate by adding final. Intent communicated!

Second challenge, mark all the local variables in the method as 
final. Now make it compile without introducing more mutable variables. At the 
end of this journey you will have about a dozen unit testable methods and a 
_distribute method that goes from ~370 lines to  ~90 with no mutable local 
variables. 

I argue it is relevant as good guardrail for writing good code. 
While we should ALWAYS strive for it we don’t. Every little nudge helps.


-Jake

Re: [VOTE] Requiring final keyword on every parameter and local variable

[Kirk Lund]

I'm planning to leave this VOTE and DISCUSSION open until Wednesday 2400 PM
UTC.

On Wed, Apr 14, 2021 at 12:55 PM Kirk Lund  wrote:

> Our coding standard and our Design Decisions does NOT require using final
> on parameters and local variables.
>
> Please do NOT request that I add or keep final on parameters or local
> variables unless the community votes and decides that every parameter and
> local variable should require the final keyword. I coded this way in the
> past and I found that it resulted in noisy code with no benefit. We can
> argue about using this keyword all you want but the fact is I'm against it,
> and I will not embrace it unless this community decides that we need to use
> it.
>
> Using final on instance or class fields does have a concurrency benefit
> and I support that only.
>
> If you want to add final to every single parameter and local var in the
> Geode codebase, then now is your chance to vote on it. Please vote.
>
> Thanks,
> Kirk
>
>

Re: [VOTE] Requiring final keyword on every parameter and local variable

[Mark Hanson]

Hi Jake,

I agree with everyone's point about final being a useful, I just don't find it 
useful enough to do anything manually across the code base at this point.

I believe first in foremost in no code warnings. Intellij warns about variables 
that can be final, so I make them final as it finds them. It is very rare that 
I am writing new code at this point. I have spent the last year bug fixing 
other people's code.  From my standpoint, original intent is largely moot. So, 
for me, the question is do I go through code that is not mine and mark it all 
as final (where appropriate)? Sure, in code that I touch. In code the rest of 
the codebase, I think there are bigger fish to fry before we get to final.

It seems like the larger portion of the consensus is to recommend that 
variables are marked final (where appropriate) as we find them or create them. 
That seems like the going forward approach consensus.

I will be blunt though. This seems nitpicky *compared* to the number of code 
warnings there are and the fact that people are not actively fixing all of the 
warnings.
If we don't come to the same consensus about all warnings this seems like 
painting a rusted car, sure it makes it all look the same, but does very little 
for the underlying problems. Now to undermine my own argument a little, I think 
that especially in release blockers, we want to touch as little code as 
possible, so I am flexible there.

I would also like to agree with Udo about final really not being very good 
compared to Mutable and Immutable objects in other languages.

Thanks,
Mark


On 4/15/21, 7:49 PM, "Udo Kohlmeyer"  wrote:

@jake, you are correct, I did miss the LOCAL variable out of the subject. 
:face_palm:

Yes, adding "final" to LOCAL variables will be HUGELY beneficial in this 
regard. Have we seen any performance improvement after having refactored this 
method? Have you been able to measure any improvements?

--Udo 

On 4/15/21, 1:19 PM, "Jacob Barrett"  wrote:



> On Apr 14, 2021, at 7:46 PM, Udo Kohlmeyer  wrote:
> @Jake the idea of smaller methods is great and we should ALWAYS 
strive for that. But that argument is completely irrelevant in this discussion. 
As making method arguments final does not naturally guide a developer to 
creating smaller methods. Nor does a smaller method mean it can/will be jitted. 
Too many factors (to discuss here) are part of that decision, also it is not 
relevant in this discussion. But more on that topic read THIS.

The original subject is in regards to parameters and local variables.

Irrelevant is certainly an opinion you are welcome to have but let me 
challenge you. Goto DistributedCacheOperation._distribute(). 

First challenge, look at around line 333: 
boolean reliableOp = isOperationReliable() && 
region.requiresReliabilityCheck();

Without scrolling do you see that variable used? Nope, because it is 
first used on line 439, ~100 lines away. Does it mutate between there, well I 
can search for all uses and find out or I could be nice to the next person and 
intend for it to never mutate by adding final. Intent communicated!

Second challenge, mark all the local variables in the method as final. 
Now make it compile without introducing more mutable variables. At the end of 
this journey you will have about a dozen unit testable methods and a 
_distribute method that goes from ~370 lines to  ~90 with no mutable local 
variables. 

I argue it is relevant as good guardrail for writing good code. While 
we should ALWAYS strive for it we don’t. Every little nudge helps.


-Jake

Re: Geode retry/acknowledge improvement

[Nabarun Nag]

Hi Mario,

Will it be possible to provide a README doc to recreate this environment to 
test the failure.  (even a DUnit test or even scripts using baremetal GemFire 
will work too)


Regards
Naba



From: Mario Ivanac 
Sent: Monday, April 19, 2021 7:16 AM
To: dev@geode.apache.org 
Subject: Geode retry/acknowledge improvement

Hi all,

we have deployed geode cluster in kubernetes environment, and Istio/SideCars 
are injected between cluster members.
While running traffic, if any Istio/SideCar is restarted, thread will get stuck 
indefinitely, while waiting for reply on sent message.
It seams that due to restarting of proxy, in some cases, messages are lost, and 
sending side is waiting indefinitely for reply.

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-9075&data=04%7C01%7Cnnag%40vmware.com%7C138a80f7772245d748a108d9033dcbbd%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637544386215065161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5XCiXedKhyFdBTU7s1qFQC834OxaaamUIAZkjfQyaoo%3D&reserved=0

My question is, what is your estimation, how much effort/work is needed to 
implement message retry/acknowledge logic in geode,
to solve this problem?

BR,
Mario

Re: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1

[Nabarun Nag]

-1

Potential rebalance issue during upgrade to 1.12.2RC1

The investigation is ongoing.  Please do give me a little more time on this.


Regards
Nabarun

From: John Blum 
Sent: Monday, April 19, 2021 9:40 AM
To: dev@geode.apache.org 
Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1

+1

Spring Data for Apache Geode 1.12.2 built successfully.

From: Dave Barnes 
Sent: Monday, April 19, 2021 9:19 AM
To: dev@geode.apache.org 
Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1

+1
Built and reviewed User Guide and API docs. LGTM.

On Wed, Apr 14, 2021 at 3:43 PM Donal Evans  wrote:

> +1
>
> Confirmed that performance in multiple scenarios is on par with the
> previous 1.12 release.
> 
> From: Owen Nichols 
> Sent: Wednesday, April 14, 2021 3:38 PM
> To: dev@geode.apache.org 
> Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1
>
> Hello Geode Dev Community,
>
> Geode’s support/1.12 has gathered a few more fixes since 1.12.1 was
> released two months ago.  I’d like to propose another patch release.
>
> This is a release candidate for Apache Geode version 1.12.2.RC1.
> 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 PDT Mon, April 19 2021.
>
> Please note that we are voting upon the source tag:
> rel/v1.12.2.RC1
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.2&data=04%7C01%7Cnnag%40vmware.com%7C30bfc2cfc5004ad1e3e608d90351dd5b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544472410940144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KFYfIsguFRxPpBXMQfNq33D9cdS%2FgRSQ2SJD39KNerk%3D&reserved=0
>
> Source and binary distributions:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.2.RC1%2F&data=04%7C01%7Cnnag%40vmware.com%7C30bfc2cfc5004ad1e3e608d90351dd5b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544472410940144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rCqkmfL9WZXuZdOX4tmR2Hw5L1atvcEuDbt5xXyD1tg%3D&reserved=0
>
> Maven staging repo:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1080&data=04%7C01%7Cnnag%40vmware.com%7C30bfc2cfc5004ad1e3e608d90351dd5b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544472410940144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=udlvzlTc5z%2BLUJkrZ5urztDD%2BgTUASjuu5bRWzrggFI%3D&reserved=0
>
> GitHub:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.2.RC1&data=04%7C01%7Cnnag%40vmware.com%7C30bfc2cfc5004ad1e3e608d90351dd5b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544472410940144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eHH9mYRrWssVvZwICeOOLphzrsivyWHIZS6QOS7CIco%3D&reserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.2.RC1&data=04%7C01%7Cnnag%40vmware.com%7C30bfc2cfc5004ad1e3e608d90351dd5b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544472410940144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Er32Xs2l6tx0QvSL1MlSBiAlcS63z1So0QC6TUsBtbE%3D&reserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.2.RC1&data=04%7C01%7Cnnag%40vmware.com%7C30bfc2cfc5004ad1e3e608d90351dd5b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544472410950132%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=w17mCNgbi12aZvnKKCIug%2B%2F5v6LnWDqcq85lUlPY4Ng%3D&reserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.2.RC1&data=04%7C01%7Cnnag%40vmware.com%7C30bfc2cfc5004ad1e3e608d90351dd5b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544472410950132%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=nWhs85ihp%2FfU0j2CqMOK%2Be7OBlEWwdqHnZ2pAWn47rk%3D&reserved=0
>
> Pipelines:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-main&data=04%7C01%7Cnnag%40vmware.com%7C30bfc2cfc5004ad1e3e608d90351dd5b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544472410950132%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI

Re: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1

[John Blum]

+1

Spring Data for Apache Geode 1.12.2 built successfully.

From: Dave Barnes 
Sent: Monday, April 19, 2021 9:19 AM
To: dev@geode.apache.org 
Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1

+1
Built and reviewed User Guide and API docs. LGTM.

On Wed, Apr 14, 2021 at 3:43 PM Donal Evans  wrote:

> +1
>
> Confirmed that performance in multiple scenarios is on par with the
> previous 1.12 release.
> 
> From: Owen Nichols 
> Sent: Wednesday, April 14, 2021 3:38 PM
> To: dev@geode.apache.org 
> Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1
>
> Hello Geode Dev Community,
>
> Geode’s support/1.12 has gathered a few more fixes since 1.12.1 was
> released two months ago.  I’d like to propose another patch release.
>
> This is a release candidate for Apache Geode version 1.12.2.RC1.
> 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 PDT Mon, April 19 2021.
>
> Please note that we are voting upon the source tag:
> rel/v1.12.2.RC1
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.2&data=04%7C01%7Cjblum%40vmware.com%7Cb5edbe932aab47ef849e08d9034ee529%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544459667984361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ycIQ4dMv%2Baot0TXuDhBsrxB7CVjtkgjJWdq6u1Sq4CQ%3D&reserved=0
>
> Source and binary distributions:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.2.RC1%2F&data=04%7C01%7Cjblum%40vmware.com%7Cb5edbe932aab47ef849e08d9034ee529%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544459667984361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=q%2FhHp%2Bg08zKQFR%2BUzBka%2FBXszgcQHX7NoOcWysIenow%3D&reserved=0
>
> Maven staging repo:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1080&data=04%7C01%7Cjblum%40vmware.com%7Cb5edbe932aab47ef849e08d9034ee529%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544459667994356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6jvQf5ga8w%2FZsvspyHHsr%2Fsn4yetQ6aC0aLHM1ndJNw%3D&reserved=0
>
> GitHub:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.2.RC1&data=04%7C01%7Cjblum%40vmware.com%7Cb5edbe932aab47ef849e08d9034ee529%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544459667994356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5oP%2BT3wXSOsH11BoOiTnZQ4KnxfTZ3OK35cvGXFWM%2FM%3D&reserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.2.RC1&data=04%7C01%7Cjblum%40vmware.com%7Cb5edbe932aab47ef849e08d9034ee529%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544459667994356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lTBAnvGiEzRniIZtNSFFqju81AZRrYwodWjGrLgD8oM%3D&reserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.2.RC1&data=04%7C01%7Cjblum%40vmware.com%7Cb5edbe932aab47ef849e08d9034ee529%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544459667994356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1NHd8IAOqmZcHgYS0BF6I4enwwxzrqRbYaB87%2Bt53NA%3D&reserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.2.RC1&data=04%7C01%7Cjblum%40vmware.com%7Cb5edbe932aab47ef849e08d9034ee529%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544459667994356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4N0XwecPOvLnE9EucTUUbhIxFnXRhdqTnMAt77RwBDo%3D&reserved=0
>
> Pipelines:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-main&data=04%7C01%7Cjblum%40vmware.com%7Cb5edbe932aab47ef849e08d9034ee529%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637544459667994356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uEniMQ%2BY7CPB7kLfgouQvH8uYJf8EHu2VCXJkd7Zp2w%3D&reserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-rc&data=04%7C01%7Cjblum%40vmware.com%7Cb5edbe932aab47ef849e08d9034ee529%7Cb39138ca3ce

Re: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1

[Dave Barnes]

+1
Built and reviewed User Guide and API docs. LGTM.

On Wed, Apr 14, 2021 at 3:43 PM Donal Evans  wrote:

> +1
>
> Confirmed that performance in multiple scenarios is on par with the
> previous 1.12 release.
> 
> From: Owen Nichols 
> Sent: Wednesday, April 14, 2021 3:38 PM
> To: dev@geode.apache.org 
> Subject: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1
>
> Hello Geode Dev Community,
>
> Geode’s support/1.12 has gathered a few more fixes since 1.12.1 was
> released two months ago.  I’d like to propose another patch release.
>
> This is a release candidate for Apache Geode version 1.12.2.RC1.
> 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 PDT Mon, April 19 2021.
>
> Please note that we are voting upon the source tag:
> rel/v1.12.2.RC1
>
> Release notes:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRelease%2BNotes%23ReleaseNotes-1.12.2&data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=FrmRSQZPUtL3pciiAZ7LnGokKWITJgbl6N9KNdCBidQ%3D&reserved=0
>
> Source and binary distributions:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fgeode%2F1.12.2.RC1%2F&data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0dc%2FB9Hnf1wK4NpLXBUpy7v7H1xj9btZgsf1EjHW2IY%3D&reserved=0
>
> Maven staging repo:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachegeode-1080&data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2T06JC%2BaRCVgViSmbwDqP6Z%2F6Y10zeIlOaTNpVwWkRA%3D&reserved=0
>
> GitHub:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Ftree%2Frel%2Fv1.12.2.RC1&data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VyruqqFrBFtwop5L9dPW%2BUI69D2ijqZS7rf1ZnHIloM%3D&reserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-examples%2Ftree%2Frel%2Fv1.12.2.RC1&data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=keT%2FsAuuqJ2jh1OAQgyAysVqNHqP%2BSJzlV%2F%2B6Yfjc9k%3D&reserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Frel%2Fv1.12.2.RC1&data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=r8HofpAFHtOKoKaeDmZFQx3x%2FLViCem3fwB5Hd1Zjvs%3D&reserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-benchmarks%2Ftree%2Frel%2Fv1.12.2.RC1&data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=fHlniSX58ttlHa1PegR5fY5y2ISh0hU8uPUH%2FQHsldg%3D&reserved=0
>
> Pipelines:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-main&data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ck4trXdfeLSrRB%2BZBU3gytEmfDHN3E52Dw6tYjKxeu0%3D&reserved=0
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-support-1-12-rc&data=04%7C01%7Cdoevans%40vmware.com%7Cf7dd0f3da7ee44537d8408d8ff9610ef%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637540367286020326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Fg7B1wfQN09lrTi%2FhvdtwdiPj8DCZjq5dD9YDjTU1FQ%3D&reserved=0
>
> 

Geode retry/acknowledge improvement

[Mario Ivanac]

Hi all,

we have deployed geode cluster in kubernetes environment, and Istio/SideCars 
are injected between cluster members.
While running traffic, if any Istio/SideCar is restarted, thread will get stuck 
indefinitely, while waiting for reply on sent message.
It seams that due to restarting of proxy, in some cases, messages are lost, and 
sending side is waiting indefinitely for reply.

https://issues.apache.org/jira/browse/GEODE-9075

My question is, what is your estimation, how much effort/work is needed to 
implement message retry/acknowledge logic in geode,
to solve this problem?

BR,
Mario