al Message-
From: Jason Huynh [mailto:jasonhu...@apache.org]
Sent: Tuesday, August 15, 2017 9:25 PM
To: dev@geode.apache.org
Subject: Re: continuous query internal mechanism questions
I am not quite sure how native client registers cqs. From my understanding:
with the java api, I believe the
;//this will go to
ThinClientDistributionManager
...
Can this be causing the issue?
-Roi
-Original Message-
From: Jason Huynh [mailto:jasonhu...@apache.org]
Sent: Tuesday, August 15, 2017 9:25 PM
To: dev@geode.apache.org
Subject: Re: continuous query internal mechanism questions
I am not quite sure ho
17 1:41 AM
To: dev@geode.apache.org
Subject: Re: continuous query internal mechanism questions
In Geode, high availability for subscription events are achieved by having
redundant event-queues (HAQueues) on multiple severs; this is configured using
redundancy-level with client connection. Based on the
In Geode, high availability for subscription events are achieved by having
redundant event-queues (HAQueues) on multiple severs; this is configured
using redundancy-level with client connection. Based on the redundancy
level, the client register CQs on multiple servers. During the subscription
I am not quite sure how native client registers cqs. From my understanding:
with the java api, I believe there is only one message (ExecuteCQ message)
that is executed on the server side and then replicated to the other nodes
through the profile (OperationMessage).
It seems the extra ExecuteCQ
Hi,
I have been examining the continuous query registration mechanism for quite
some time
This is related to an issue that I have, where sometimes a node crashes (1 node
out of 2), and the other one does not send CQ events. The CQ is registered on a
partitioned region which resides on these 2
