Re: Cached regions are not synchronized after restore

Hi, Thanks for pointing that part of the documentation. Ok I understand now that if cache consistency for certain keys is a concern, the user should register interest for such keys. And with that premise my scenario does not happens, so I guess I'll go for the Java client implementation in geode

Re: Cached regions are not synchronized after restore

Here's the doc I was referring (the one Dan mentioned) to: https://geode.apache.org/docs/guide/12/developing/events/how_client_server_distribution_works.html#how_client_server_distribution_works__section_928BB60066414BEB9FAA7FB3120334A3 Specifically, see the section under Server Failover: "...For

Client Acceptor pool hangs

Hi, We are encountering the following deadlock (pretty often) on 1.13.1: 1. Client (bridge) acceptor thread is locked up in this stack "Handshaker 0.0.0.0/0.0.0.0:40011 Thread 2" #219 daemon prio=5 os_prio=0 tid=0x7f755c007000 nid=0x44a2 runnable [0x7f75847c7000] java.lang.Thread.Stat

Re: [PROPOSAL] backport GEODE-8998 to 1.14

+1 On 3/4/21, 9:37 AM, "Darrel Schneider" wrote: I'm resending this request because my previous request was labelled as junk. 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 moni

Re: [Suspected Spam] [PROPOSAL] backport GEODE-8998 to 1.14

+1 On 3/4/21, 9:31 AM, "Mark Hanson" wrote: +1 On 3/3/21, 5:18 PM, "Darrel Schneider" wrote: 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 disab

Re: [PROPOSAL] backport GEODE-8998 to 1.14

+1 On Thu, Mar 4, 2021 at 9:37 AM Darrel Schneider wrote: > I'm resending this request because my previous request was labelled as > junk. > > 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 m

[PROPOSAL] backport GEODE-8998 to 1.14

I'm resending this request because my previous request was labelled as junk. 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 n

Re: Cached regions are not synchronized after restore

Actually, I believe that is correct. I.e., clients should only drop stuff they've registered interest in. I'll see if I can find the docs for this. Consider using a local cache to store read-only data --- maybe a product catalog, that only gets updated on the first of the month. There would be n

Re: [Suspected Spam] [PROPOSAL] backport GEODE-8998 to 1.14

+1 On 3/3/21, 5:18 PM, "Darrel Schneider" wrote: 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 k

Re: Cached regions are not synchronized after restore

Hi Mike, Thanks for looking into it. However, thing is, not all entries all cleared in the case of the Java client, just the keys which interest it’s registered. I think that might not be correct :S BR, Mario Obtener Outlook para iOS De:

Re: Cached regions are not synchronized after restore

It seems like this is a NC bug. I'll write a test for your scenario, but it seems like the NC is not dropping its local cache (i.e., clearing all local entries) on a server restore. As Dan has indicated, the Java client will clear a local cache when it loses connectivity to all servers, which is

Re: [PROPOSAL]: Add GEODE-9000 as Geode 1.14.0 Blocker

I'm sorry, Dave. I'm afraid I can't do that. Oh wait that was HAL-9000. GEODE-9000 added to blocker board ;) On 3/4/21, 9:04 AM, "Darrel Schneider" wrote: +1 I agree this should be fixed in 1.14 From: Ju@N Sent: Thursday, March 4, 2021 3:30 AM

Re: [PROPOSAL]: Add GEODE-9000 as Geode 1.14.0 Blocker

+1 I agree this should be fixed in 1.14 From: Ju@N Sent: Thursday, March 4, 2021 3:30 AM To: dev@geode.apache.org Subject: [PROPOSAL]: Add GEODE-9000 as Geode 1.14.0 Blocker Hello team, I'd like to propose adding a newly created ticket, *GEODE-9000 [1]*, to the

Re: Cached regions are not synchronized after restore

Hi again, While looking into how Java client ensures cache consistency after a cluster restart, I've seen that this is achieved by recovering previously registered interest. However, I noticed the following scenario which outcome does not seem correct to me: 1. Start a cluster with a REPLIC

[PROPOSAL]: Add GEODE-9000 as Geode 1.14.0 Blocker

Hello team, I'd like to propose adding a newly created ticket, *GEODE-9000 [1]*, to the *1.14.0 Blocker Board* [2] The issue has been recently introduced and, long story short, it prevents members from automatically reconnecting to a distributed system after a full network split - usage of PERSIST

Re: Cached regions are not synchronized after restore

Hi, Well, thing is Mike you raised an interesting topic here, because I wasn't seeing the behavior of GF_CACHE_CONCURRENT_MODIFICATION_EXCEPTION as incorrect, rather the fact that entries where not cleaned up after subscription redundancy is lost. But interestingly, I've been asked that why aft