subject:"RE\: continuous query internal mechanism"

RE: continuous query internal mechanism questions

2017-09-05 Thread Roi Apelker

Hi,

After quite some time, I was getting back to this issue where something seems 
wrong with the registration of CQ.

In the java client I see that the code goes to a method called " 
executeCqOnRedundantsAndPrimary " which seems indeed to go to all the relevant 
servers and register the CQ.

Why would there be a need to register the CQ in more than one server, if that 
first server also notifies all the others about the registration?

(the initial registration is with an actual CQ Message, then the server 
notifies the others with  DistributionMessage)

Thanks

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 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 message failing and then closing the cq might be 
putting the system in a weird state...

On Tue, Aug 15, 2017 at 7:56 AM Roi Apelker <roi.apel...@amdocs.com> wrote:

> 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:aging...@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.apel...@amdocs.com>
> wrote:
>
> > Shukriya
> >
> > What is the difference between registered events and CQ events?
> >
> > -Original Message-
> > From: Anilkumar Gingade [mailto:aging...@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 
> > ClientUpdateMess

RE: continuous query internal mechanism questions

2017-08-16 Thread Roi Apelker

It seems like the code in the native client (in the version I have, which may 
be old) send the message to all servers:

CqResultsPtr CqQueryImpl::executeWithInitialResults(uint32_t timeout)
{
  ...

  TcrMessage msg(TcrMessage::EXECUTECQ_WITH_IR_MSG_TYPE, m_cqName, 
m_queryString, CqState::RUNNING, isDurable(), m_tccdm);
  TcrMessage reply(true, m_tccdm);
  ChunkedQueryResponse* resultCollector = (new ChunkedQueryResponse(reply));
  reply.setChunkedResultHandler(static_cast(resultCollector));
  reply.setTimeout(timeout);

  GfErrType err = GF_NOERR;
  err = m_tccdm->sendSyncRequest(msg, reply);
..

And sendSyncRequest:
...

for (std::vector<TcrEndpoint*>::iterator ep = m_endpoints.begin(); ep != 
m_endpoints.end(); ++ep) {
if ((*ep)->connected()) {
  (*ep)->setDM(this);
  opErr = sendRequestToEP(request, reply, *ep);//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 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 message failing and then closing the cq might be 
putting the system in a weird state...

On Tue, Aug 15, 2017 at 7:56 AM Roi Apelker <roi.apel...@amdocs.com> wrote:

> 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:aging...@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.apel...@amdocs.com>
> wrote:
>
> > Shukriya
> >
> > What is the difference between registered events and CQ events?
> >
> > -Original Message-
> > From: Anilkumar Gingade [mailto:aging...@pivotal.io]
> > Sent: Monday, August 07, 2017 10:12 PM
> > To: dev@geode.apache.org
> > Subject: Re: continuous query internal mechanism
> >
> > CQ Pr

RE: continuous query internal mechanism questions

2017-08-16 Thread Roi Apelker

Thanks,
The subscription-redundancy is set to "1" and the region is used in 2 nodes 
(there are more nodes which re not related to it).

Yes there is an exception, which I am yet to understand: (and this exception 
causes the closure of the CQ in this node as well as sending operation message 
to the other node to close!)

caught exception while running: 
java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
at sun.nio.ch.IOUtil.write(IOUtil.java:51)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
at 
org.apache.geode.internal.cache.tier.sockets.Message.flushBuffer(Message.java:651)
at 
org.apache.geode.internal.cache.tier.sockets.Message.sendBytes(Message.java:632)
at 
org.apache.geode.internal.cache.tier.sockets.ChunkedMessage.sendChunk(ChunkedMessage.java:314)
at 
org.apache.geode.internal.cache.tier.sockets.ChunkedMessage.sendChunk(ChunkedMessage.java:322)
at 
org.apache.geode.internal.cache.tier.sockets.BaseCommand.writeQueryResponseChunk(BaseCommand.java:756)
at 
org.apache.geode.internal.cache.tier.sockets.BaseCommandQuery.processQueryUsingParams(BaseCommandQuery.java:225)
at 
org.apache.geode.internal.cache.tier.sockets.BaseCommandQuery.processQuery(BaseCommandQuery.java:70)
at 
org.apache.geode.internal.cache.tier.sockets.command.ExecuteCQ61.cmdExecute(ExecuteCQ61.java:179)
at 
org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:147)
at 
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:783)
at 
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:913)
at 
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1143)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:546)
at java.lang.Thread.run(Thread.java:745)

could it be the client disconnected from the node right after sending this 
message? (The client itself continues to run normally...)
The scenario is that after all nodes are initialized, I am stopping one server 
out of 2. Sometimes, 1 out of 5 - the CQ stops notifying the client after this 
stop. Most if the time the CQ continues to run fine.
I am certain this is related to some timing issue, some registration which 
fails, something also related to the filter profiles which is held in the 
region...

Thanks

Roi

-Original Message-
From: Anilkumar Gingade [mailto:aging...@pivotal.io] 
Sent: Wednesday, August 16, 2017 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 redundancy level, the 
client register CQs on multiple servers. During the subscription
(CQ) registration, it elects/assigns one of the server to host primary HAQueue.

The client keeps monitoring the redundancy level during node join or failure; 
to satisfy the redundancy level.

You can find more about HAQueues at
https://cwiki.apache.org/confluence/display/GEODE/HA+Client+Event+Queues

I assume, you have 2 node cluster. What is your subscription redundancy level?

>> For some reason, sometimes there is a failure to complete the first
registration
Is there any log message, stack trace, reporting reason for failure? If its dev 
environment, you can run client/server with debug/fine level log to see 
additional info.

Are you trying to stop your server, while registering the CQs? Can you give 
more detail about your test scenario...

-Anil.


On Tue, Aug 15, 2017 at 11:25 AM, Jason Huynh <jasonhu...@apache.org> wrote:

> 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 message failing and then closing the cq 
> might be putting the system in a weird state...
>
> On Tue, Aug 15, 2017 at 7:56 AM Roi Apelker <roi.apel...@amdocs.com>
> wrote:
>
> > 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
&g

Re: continuous query internal mechanism questions

2017-08-15 Thread Anilkumar Gingade

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
(CQ) registration, it elects/assigns one of the server to host primary
HAQueue.

The client keeps monitoring the redundancy level during node join or
failure; to satisfy the redundancy level.

You can find more about HAQueues at
https://cwiki.apache.org/confluence/display/GEODE/HA+Client+Event+Queues

I assume, you have 2 node cluster. What is your subscription redundancy
level?

>> For some reason, sometimes there is a failure to complete the first
registration
Is there any log message, stack trace, reporting reason for failure? If its
dev environment, you can run client/server with debug/fine level log to see
additional info.

Are you trying to stop your server, while registering the CQs? Can you give
more detail about your test scenario...

-Anil.


On Tue, Aug 15, 2017 at 11:25 AM, Jason Huynh <jasonhu...@apache.org> wrote:

> 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 message failing and then closing the cq might
> be putting the system in a weird state...
>
> On Tue, Aug 15, 2017 at 7:56 AM Roi Apelker <roi.apel...@amdocs.com>
> wrote:
>
> > 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:aging...@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.apel...@amdocs.com>
> > wrote:
> >
> > >

Re: continuous query internal mechanism questions

2017-08-15 Thread Jason Huynh

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 message failing and then closing the cq might
be putting the system in a weird state...

On Tue, Aug 15, 2017 at 7:56 AM Roi Apelker <roi.apel...@amdocs.com> wrote:

> 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:aging...@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.apel...@amdocs.com>
> wrote:
>
> > Shukriya
> >
> > What is the difference between registered events and CQ events?
> >
> > -Original Message-
> > From: Anilkumar Gingade [mailto:aging...@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.apel...@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 :-)
> >

RE: continuous query internal mechanism

2017-08-09 Thread Roi Apelker

Dhanyavad

-Original Message-
From: Anilkumar Gingade [mailto:aging...@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.apel...@amdocs.com> wrote:

> Shukriya
>
> What is the difference between registered events and CQ events?
>
> -Original Message-
> From: Anilkumar Gingade [mailto:aging...@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.apel...@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:aging...@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.apel...@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>

RE: continuous query internal mechanism

2017-08-08 Thread Roi Apelker

Shukriya

What is the difference between registered events and CQ events?

-Original Message-
From: Anilkumar Gingade [mailto:aging...@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.apel...@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:aging...@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.apel...@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>

Re: continuous query internal mechanism

2017-08-07 Thread Anilkumar Gingade

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.apel...@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:aging...@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.apel...@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>
>

RE: continuous query internal mechanism

2017-08-07 Thread Roi Apelker

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:aging...@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.apel...@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>

Re: continuous query internal mechanism

2017-08-07 Thread Anilkumar Gingade

You can find those in CqServiceImpl.process*()...

-Anil.


On Mon, Aug 7, 2017 at 9:14 AM, Roi Apelker  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>
>

RE: continuous query internal mechanism questions

RE: continuous query internal mechanism questions

RE: continuous query internal mechanism questions

Re: continuous query internal mechanism questions

Re: continuous query internal mechanism questions

RE: continuous query internal mechanism

RE: continuous query internal mechanism

Re: continuous query internal mechanism

RE: continuous query internal mechanism

Re: continuous query internal mechanism

10 matches

Site Navigation

Mail list logo

Footer information