geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roi Apelker <Roi.Apel...@amdocs.com>
Subject continuous query internal mechanism questions
Date Tue, 15 Aug 2017 14:56:13 GMT
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 nodes.

I noticed the following behavior, and I wonder if anyone can comment regarding it, if it is
justified or not and what is the reason:

1. When the software using the client (native client) registers for the CQ, a CQ command (ExecuteCQ61)
is received on both servers.
 -- is this normal behaviour? Does the client actually send this command to both servers?

2. When this command is received by a server, and the CQ is registered, another registration
message is sent to the other node via an OperationMessage (REGISTER_CQ)
 -- it seems that regularly, the server can handle this situation as the second registration
identifies the previous one and does not affect it. but the question, why do we need this
2nd registration, if there is a command sent to each server?

3. For some reason, sometimes there is a failure to complete the first registration (executed
by ExecuteCQ61) and then this failure causes a closure to the CQ, which is accompanied with
a close request to the other node.
 -- I assume by now, since 2 registrations and one closure have occurred on node 2, the CQ
is still active and the client receives notifications.

4. Sometimes, 1 out of 5, once node 1 crashes, I get a cleanup operation, caused by the crash
(via MemberCrashedEvent), and this also closes the existing CQ, and in this case the CQ in
node 2 does not operate anymore and the client receives no notifications.
 -- fact is, that 4 out of 4 times, I do not get this cleanup by MemberCrashedEvent (maybe
due to some other error), and that the CQ notifications are received normally.

Can anyone clear things up for me? Any comment on any of the statements above will be greatly
appreciated. 
 
Thanks,

Roi


-----Original Message-----
From: Roi Apelker 
Sent: Wednesday, August 09, 2017 3:21 PM
To: dev@geode.apache.org
Subject: RE: continuous query internal mechanism

Dhanyavad

-----Original Message-----
From: Anilkumar Gingade [mailto:agingade@pivotal.io]
Sent: Tuesday, August 08, 2017 9:55 PM
To: dev@geode.apache.org
Subject: Re: continuous query internal mechanism

Registered events, i meant, are events generated for interest registration "region.registerInterest(*)".
And CqEvents are for CQs registered.

-Anil.


On Tue, Aug 8, 2017 at 12:27 AM, Roi Apelker <Roi.Apelker@amdocs.com> wrote:

> Shukriya
>
> What is the difference between registered events and CQ events?
>
> -----Original Message-----
> From: Anilkumar Gingade [mailto:agingade@pivotal.io]
> Sent: Monday, August 07, 2017 10:12 PM
> To: dev@geode.apache.org
> Subject: Re: continuous query internal mechanism
>
> CQ Processing on server side is same for all clients (Java, C++)...
>
> The subscription events are sent to client as ClientUpdateMessage, 
> which holds information about registered events and CQ events. The 
> client process this and updates/invokes the client side 
> cache/listeners with respective event. Look into 
> ClientUpdateMessageImpl and CacheClientUpdater (for client side processing).
>
> -Anil.
>
>
>
>
> On Mon, Aug 7, 2017 at 11:01 AM, Roi Apelker <Roi.Apelker@amdocs.com>
> wrote:
>
> > Thanks,
> >
> > By the way, is there any difference in the behaviour of the server, 
> > if the client that registered the CQ is a native (C++) client?
> >
> > I have been going over the classes and code for some time and can't 
> > seem to find the actual location where a CQ update/notification is
> sent...
> >
> > It's like CqEventImpl class is never even generated in this scenario.
> >
> > If anyone can help here I would be most grateful :-)
> >
> > Thanks
> >
> > Roi
> >
> >
> >
> > -----Original Message-----
> > From: Anilkumar Gingade [mailto:agingade@pivotal.io]
> > Sent: Monday, August 07, 2017 8:23 PM
> > To: dev@geode.apache.org
> > Subject: Re: continuous query internal mechanism
> >
> > You can find those in CqServiceImpl.process*()...
> >
> > -Anil.
> >
> >
> > On Mon, Aug 7, 2017 at 9:14 AM, Roi Apelker <Roi.Apelker@amdocs.com>
> > wrote:
> >
> > > Hello,
> > >
> > > I am trying to look into the code of the continuous query 
> > > mechanism
> > > - where the GEODE server sends the notification back to the client.
> > >
> > > Can anyone point me to the central classes of continuous query, 
> > > especially to the one that is responsible for the calculation of 
> > > the new data and packing it as a message back to the client?
> > >
> > > Thanks,
> > >
> > > Roi
> > >
> > > This message and the information contained herein is proprietary 
> > > and confidential and subject to the Amdocs policy statement,
> > >
> > > you may review at https://www.amdocs.com/about/email-disclaimer < 
> > > https://www.amdocs.com/about/email-disclaimer>
> > >
> > This message and the information contained herein is proprietary and 
> > confidential and subject to the Amdocs policy statement,
> >
> > you may review at https://www.amdocs.com/about/email-disclaimer < 
> > https://www.amdocs.com/about/email-disclaimer>
> >
> This message and the information contained herein is proprietary and 
> confidential and subject to the Amdocs policy statement,
>
> you may review at https://www.amdocs.com/about/email-disclaimer < 
> https://www.amdocs.com/about/email-disclaimer>
>
This message and the information contained herein is proprietary and confidential and subject
to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer <https://www.amdocs.com/about/email-disclaimer>
This message and the information contained herein is proprietary and confidential and subject
to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer <https://www.amdocs.com/about/email-disclaimer>
Mime
View raw message