You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geode.apache.org by Leon Finker <le...@gmail.com> on 2020/12/08 21:42:14 UTC

Client Regions, register interest and geode client reconnect

Hi,

We noticed that in QueueManagerImpl.recoverSingleKey upon network
reconnect, the local Region entries are basically destroyed before being
populated again. If we do lookup of data at this timeframe, then data is
not found. How can this race condition be avoided?

Re: Client Regions, register interest and geode client reconnect

Posted by Leon Finker <le...@gmail.com>.
The region type is caching proxy with register interest for all keys. Yes
during this time window when geode client reconnects, the keys available
through Region.keySet call are not the same as before reconnect or after
reconnect. As well as doing Region.getAll(Region.keySet)) throws
EntryDestroyedException. I realize now that this will also fail for OQL and
Region.values most likely?

Looking at the code, not sure how this can even be avoided by everyone.
QueueManagerImpl.recoverSingleKey and when primary endpoint recovered, it
issues Region.clearKeysOfInterest then eventually calls
 case InterestType.KEY:
        if (key instanceof String && key.equals("ALL_KEYS")) {
          clearViaRegEx(".*");
...
for (Object o : entrySet(false)) {
...
localDestroyNoCallbacks(entryKey);

This is really unexpected behavior and impossible to deal with. Everyone
would have to either create local disconnected region paired with proxy
empty region and forward events. Or always call keySetOnServer.

Am I missing something here?

On Wed, Dec 9, 2020 at 12:59 PM Anilkumar Gingade <ag...@vmware.com>
wrote:

> When you say region entries are destroyed; are those keys/entries are not
> present or keys are present but no/null values?
>
>
>
> In case of re-connect the interests are re-registered to get the latest
> snapshot from the server. During this time the local/client region values
> should be invalidated and any get() on the region should be forwarded to
> server and the data is fetched from the server, if I remember correct.
>
>
>
> What kind of region client has, proxy, caching proxy?
>
>
>
> -Anil.
>
>
>
>
>
> *From: *Leon Finker <le...@gmail.com>
> *Reply-To: *"user@geode.apache.org" <us...@geode.apache.org>
> *Date: *Tuesday, December 8, 2020 at 1:42 PM
> *To: *"user@geode.apache.org" <us...@geode.apache.org>
> *Subject: *Client Regions, register interest and geode client reconnect
>
>
>
> Hi,
>
>
>
> We noticed that in QueueManagerImpl.recoverSingleKey upon network
> reconnect, the local Region entries are basically destroyed before being
> populated again. If we do lookup of data at this timeframe, then data is
> not found. How can this race condition be avoided?
>

Re: Client Regions, register interest and geode client reconnect

Posted by Anilkumar Gingade <ag...@vmware.com>.
When you say region entries are destroyed; are those keys/entries are not present or keys are present but no/null values?

In case of re-connect the interests are re-registered to get the latest snapshot from the server. During this time the local/client region values should be invalidated and any get() on the region should be forwarded to server and the data is fetched from the server, if I remember correct.

What kind of region client has, proxy, caching proxy?

-Anil.


From: Leon Finker <le...@gmail.com>
Reply-To: "user@geode.apache.org" <us...@geode.apache.org>
Date: Tuesday, December 8, 2020 at 1:42 PM
To: "user@geode.apache.org" <us...@geode.apache.org>
Subject: Client Regions, register interest and geode client reconnect

Hi,

We noticed that in QueueManagerImpl.recoverSingleKey upon network reconnect, the local Region entries are basically destroyed before being populated again. If we do lookup of data at this timeframe, then data is not found. How can this race condition be avoided?