Re: [Proposal] Backport GEODE-8958 into 1.14.x, 1.13.x, 1.12.x branches

[Xiaojian Zhou]

+1

On 3/1/21, 11:30 PM, "Owen Nichols"  wrote:

That sounds a lot better than never expiring them if that does happen, I 
think this would be good to include.

On 3/1/21, 2:41 PM, "Mark Hanson"  wrote:

I would like to backport GEODE-8958 into previous release branches to 
alleviate a problem with tombstones if timestamps become corrupt for some 
reason.

Thanks,
Mark

Re: [Proposal] Backport GEODE-8958 into 1.14.x, 1.13.x, 1.12.x branches

[Darrel Schneider]

+1

From: Xiaojian Zhou 
Sent: Wednesday, March 3, 2021 9:43 AM
To: dev@geode.apache.org 
Subject: Re: [Proposal] Backport GEODE-8958 into 1.14.x, 1.13.x, 1.12.x branches

+1

On 3/1/21, 11:30 PM, "Owen Nichols"  wrote:

That sounds a lot better than never expiring them if that does happen, I 
think this would be good to include.

On 3/1/21, 2:41 PM, "Mark Hanson"  wrote:

I would like to backport GEODE-8958 into previous release branches to 
alleviate a problem with tombstones if timestamps become corrupt for some 
reason.

Thanks,
Mark

Re: [Proposal] Backport GEODE-8958 into 1.14.x, 1.13.x, 1.12.x branches

[Jianxia Chen]

+1

On Wed, Mar 3, 2021 at 9:44 AM Darrel Schneider  wrote:

> +1
> 
> From: Xiaojian Zhou 
> Sent: Wednesday, March 3, 2021 9:43 AM
> To: dev@geode.apache.org 
> Subject: Re: [Proposal] Backport GEODE-8958 into 1.14.x, 1.13.x, 1.12.x
> branches
>
> +1
>
> On 3/1/21, 11:30 PM, "Owen Nichols"  wrote:
>
> That sounds a lot better than never expiring them if that does happen,
> I think this would be good to include.
>
> On 3/1/21, 2:41 PM, "Mark Hanson"  wrote:
>
> I would like to backport GEODE-8958 into previous release branches
> to alleviate a problem with tombstones if timestamps become corrupt for
> some reason.
>
> Thanks,
> Mark
>
>
>

[Proposal] Backport GEODE-8671 to 1.14.x, 1.13.x and 1.12.x branches

[Jianxia Chen]

I would like to backport the fix of GEODE-8671, currently a 1.14 blocker,
to support/1.14, support 1.13 and support/1.12. This would help avoid Pdx
corruption.

Thanks,
Jianxia

Re: [Proposal] Backport GEODE-8671 to 1.14.x, 1.13.x and 1.12.x branches

[Mark Hanson]

+1

On 3/3/21, 10:24 AM, "Jianxia Chen"  wrote:

I would like to backport the fix of GEODE-8671, currently a 1.14 blocker,
to support/1.14, support 1.13 and support/1.12. This would help avoid Pdx
corruption.

Thanks,
Jianxia

Re: Cached regions are not synchronized after restore

[Mike Martell]

Hi Mario,

Thanks for discovering this difference in behavior between the geode-native 
clients (C++ and .NET) and geode Java client regarding the sync'ing of local 
caches after a restore operation.

It looks like geode-native has no tests for the exception type you're seeing: 
GF_CACHE_CONCURRENT_MODIFICATION_EXCEPTION

We definitely should write a test around this functionality using our new 
testing framework and then fix the new failing test.

If you're not familiar with our new test framework, I'd be happy to walk you 
through it. It's much nicer!

Thanks,
Mike.

From: Mario Salazar de Torres 
Sent: Monday, March 1, 2021 6:38 PM
To: dev@geode.apache.org 
Subject: Re: Cached regions are not synchronized after restore

Hi everyone,

After replicating the test with both clients being the Java implementation, I 
could verify that what @Dan Smith pointed out about 
the documentation is happening. Every time subscription redundancy is lost, 
cached entries are erased. This is clearly not happening in geode-native.
So, I will further investigate to bring this functionality into the native 
client.

Thanks for the help 🙂
BR/
Mario

From: Dan Smith 
Sent: Monday, March 1, 2021 5:27 PM
To: dev@geode.apache.org 
Subject: Re: Cached regions are not synchronized after restore

The java client at least should automatically drop its cache when it loses and 
restores connectivity to all the servers. See 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Fdocs%2Fguide%2F12%2Fdeveloping%2Fevents%2Fhow_client_server_distribution_works.html%23how_client_server_distribution_works__section_928BB60066414BEB9FAA7FB3120334A3&data=04%7C01%7Cmartellm%40vmware.com%7Cf889a418de304df8b09708d8dd245484%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637502495409048002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GIbtpxg%2F4iaUC0dqu9JwUtUu9TaDK%2B4YjRAKiSgekGI%3D&reserved=0

-Dan


From: Jacob Barrett 
Sent: Friday, February 26, 2021 9:29 AM
To: dev@geode.apache.org 
Subject: Re: Cached regions are not synchronized after restore

For clarification, does the a Java client show the same behavior in missing the 
events after restore or is this something you are saying is unique to the 
native clients?

> On Feb 26, 2021, at 4:48 AM, Mario Salazar de Torres 
>  wrote:
>
> Hi,
> These months I have been tackling a series of issues having to do with 
> several inconsistencies in the geode-native client after a cluster restore.
> The later one has to do with subscription notification and cached regions. 
> The scenario is as follows:
>
>  1.  Start the cluster and the clients. For clarification purposes let's say 
> we have a NC and a Java client. Being the NC the local client, and Java 
> client the external one.
> Also note that NC client has subscription notification enabled for its pool 
> and the region has caching enabled.
>  2.  Register interest for all the region entries.
>  3.  Write some entries into the region from the Java client. Notifications 
> are received in the NC client and entries cached.
>  4.  Take a backup of the disk-stores.
>  5.  Write/modify some entries with the Java client. Notifications are 
> received in the NC client and entries cached.
>  6.  Restore the previous backup.
>  7.  Write/modify some entries with the Java client. Some of the 
> notifications are discarded and some others not.
> Note that all the entries which notifications were ignored did not exist in 
> the step 4 of the scenario.
>
> The reason why notifications mentioned in step 7 are ignored is due to the 
> following log:
> "Region::localUpdate: updateNoThrow for key [] failed 
> because the cache already contains an entry with higher version. The cache 
> listener will not be invoked"
>
> So, first of, I wanted to ask:
>
>  *   Any of you have encountered this issue before? How did you tackle it?
>  *   Is there any mechanism in the Java client to avoid this kind of issues 
> with caching de-sync? Note that I did not found any
>  *   Maybe we should add an option to clear local cached regions after 
> connection is lost towards the cluster in the same way is done with 
> PdxTypeRegistry?
>  *   Maybe any other solution having to do with cluster versioning?
>
> BR,
> Mario.

Re: [Proposal] Backport GEODE-8671 to 1.14.x, 1.13.x and 1.12.x branches

[Owen Nichols]

This was already added to the 1.14.0 blocker board on Feb 19 so you are free to 
backport it anytime, no need for additional proposal.  Additionally 
support/1.13 and support/1.12 do not have an active Geode release proposal or 
release manager so it's fine to bring fixes any time.

On 3/3/21, 11:03 AM, "Mark Hanson"  wrote:

+1

On 3/3/21, 10:24 AM, "Jianxia Chen"  wrote:

I would like to backport the fix of GEODE-8671, currently a 1.14 
blocker,
to support/1.14, support 1.13 and support/1.12. This would help avoid 
Pdx
corruption.

Thanks,
Jianxia

Re: [Proposal] Backport GEODE-8671 to 1.14.x, 1.13.x and 1.12.x branches

[Jianxia Chen]

Thanks Owen!

On Wed, Mar 3, 2021 at 11:33 AM Owen Nichols  wrote:

> This was already added to the 1.14.0 blocker board on Feb 19 so you are
> free to backport it anytime, no need for additional proposal.  Additionally
> support/1.13 and support/1.12 do not have an active Geode release proposal
> or release manager so it's fine to bring fixes any time.
>
> On 3/3/21, 11:03 AM, "Mark Hanson"  wrote:
>
> +1
>
> On 3/3/21, 10:24 AM, "Jianxia Chen"  wrote:
>
> I would like to backport the fix of GEODE-8671, currently a 1.14
> blocker,
> to support/1.14, support 1.13 and support/1.12. This would help
> avoid Pdx
> corruption.
>
> Thanks,
> Jianxia
>
>
>

Re: [PROPOSAL] backport fix for GEODE-8920 to 1.14.0

[Kirk Lund]

+1 to back-port GEODE-8920 fix

On Mon, Mar 1, 2021 at 1:23 PM Owen Nichols  wrote:

> Sounds reasonable for same reasons as GEODE-8919.  I've added it to 1.14.0
> blocker board.
>
> On 3/1/21, 1:20 PM, "Kamilla Aslami"  wrote:
>
> Hi all,
>
> I would like to back-port the fix for GEODE-8920 to 1.14.0. It
> modified debug logging in DirectChannel to make it easier to trace a
> message. This change is low-risk and important for debugging.
>
> Thanks,
> Kamilla
>
>

Re: [Proposal] Backport GEODE-8958 into 1.14.x, 1.13.x, 1.12.x branches

[Kirk Lund]

+1

On Wed, Mar 3, 2021 at 9:51 AM Jianxia Chen  wrote:

> +1
>
> On Wed, Mar 3, 2021 at 9:44 AM Darrel Schneider  wrote:
>
> > +1
> > 
> > From: Xiaojian Zhou 
> > Sent: Wednesday, March 3, 2021 9:43 AM
> > To: dev@geode.apache.org 
> > Subject: Re: [Proposal] Backport GEODE-8958 into 1.14.x, 1.13.x, 1.12.x
> > branches
> >
> > +1
> >
> > On 3/1/21, 11:30 PM, "Owen Nichols"  wrote:
> >
> > That sounds a lot better than never expiring them if that does
> happen,
> > I think this would be good to include.
> >
> > On 3/1/21, 2:41 PM, "Mark Hanson"  wrote:
> >
> > I would like to backport GEODE-8958 into previous release
> branches
> > to alleviate a problem with tombstones if timestamps become corrupt for
> > some reason.
> >
> > Thanks,
> > Mark
> >
> >
> >
>

[PROPOSAL] backport GEODE-8998 to 1.14

[Darrel Schneider]

I would like to backport GEODE-8998 to 1.14. If fixes an NPE
that will cause the geode cluster to not be able to do any
cluster messaging if thread monitoring is disabled.
This bug has never been released so it would be nice
keep it that way.

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