You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geode.apache.org by Olivier Mallassi <ol...@gmail.com> on 2018/01/24 10:53:39 UTC
client notification & message ack
All
I have a question concerning client notification and, let's say "guaranteed
delivery".
In some of our modules, we have consumers that register interest in
modification of keys that are present in Geode. Quite usual, we use the
client notifications and "register Interest", and behind the scene, Geode
creates a "subscription" that will buffer notifications for this consumer.
I am wondering how Geode decide if a notification has been consumed or not
by the consumer (and decide to delete the notification from the
subscription)?
To be more concrete, in a JMS world (or equivalent), this is something you
can control with transactions or by manually acknowledging the message.
Can we have the same kind of semantics? is this automatic when the
CacheListener callbacks end? is it only relying on the
subscription-message-tracking-timeout parameter?
Thanks for your help.
Olivier.
Re: client notification & message ack
Posted by Barry Oglesby <bo...@pivotal.io>.
Olivier,
Just to be clear, that was logging I added to a local build. The fine-level
logging doesn't have much in the code around adding to the ack map.
Thanks,
Barry Oglesby
On Thu, Jan 25, 2018 at 1:24 AM, Olivier Mallassi <
olivier.mallassi@gmail.com> wrote:
> gentlemen, thank you.
> I did not think about activating finest log levels. sorry about this.
>
>
>
> On Wed, Jan 24, 2018 at 8:38 PM, Barry Oglesby <bo...@pivotal.io>
> wrote:
>
>> What Anil and Dan said is true for durable clients, but for non-durable
>> clients, the event can potentially be acked before the event is processed
>> on the client. The CacheClientUpdater processMessages method invokes
>> verifyIfDuplicate both before and after the processing of the event. That
>> method takes a boolean whether or not to add the event id to the map of
>> events to be acked. In the non-durable case, the event is added to the map
>> in the first verifyIfDuplicate call before the event is processed. In the
>> durable case, the event is added to the map in the second call after the
>> event is processed.
>>
>> I added some logging to show the different behavior:
>>
>> Non-durable Case:
>>
>> In the non-durable case, you can see the event being acked by the
>> poolTimer-pool-2 thread before it has been processed by the Cache Client
>> Updater Thread.
>>
>> Cache Client Updater Thread on 192.168.2.4(server-1:66257)<v13>:1025
>> port 62309: CacheClientUpdater.processMessages about to
>> verifyIfDuplicate before processing event addToMap=true
>> Cache Client Updater Thread on 192.168.2.4(server-1:66257)<v13>:1025
>> port 62309: TestListener about to sleep for 2000ms before processing event
>> 1: CREATE->0->[B@6883047e->EventID[192.168.2.4(client-feeder:
>> loner):62321:22179c29:client-feeder;threadID=1;sequenceID=0]
>> poolTimer-pool-2: ThreadIdToSequenceIdExpiryTask.sendPeriodicAck about
>> to ack events=[EventID[192.168.2.4(client-feeder:loner):62321:22179
>> c29:client-feeder;threadID=1;sequenceID=0]]
>> poolTimer-pool-2: ThreadIdToSequenceIdExpiryTask.sendPeriodicAck done
>> ack events=[EventID[192.168.2.4(client-feeder:loner):62321:22179
>> c29:client-feeder;threadID=1;sequenceID=0]]
>> Cache Client Updater Thread on 192.168.2.4(server-1:66257)<v13>:1025
>> port 62309: TestListener processed event 2: CREATE after sleeping for 2000
>> ms: 0->[B@6883047e->EventID[192.168.2.4(client-feeder:loner):623
>> 21:22179c29:client-feeder;threadID=1;sequenceID=0]
>>
>> Durable Case:
>>
>> In the durable case, you can see the event being acked by the
>> poolTimer-pool-2 thread after it has been processed by the Cache Client
>> Updater Thread.
>>
>> Cache Client Updater Thread on 192.168.2.4(server-1:66336)<v15>:1025
>> port 62365: CacheClientUpdater.processMessages about to
>> verifyIfDuplicate before processing event addToMap=false
>> Cache Client Updater Thread on 192.168.2.4(server-1:66336)<v15>:1025
>> port 62365: TestListener about to sleep for 2000ms before processing event
>> 1: CREATE->0->[B@29004f90->EventID[192.168.2.4(client-feeder:
>> loner):62377:a3e29f29:client-feeder;threadID=1;sequenceID=0]
>> Cache Client Updater Thread on 192.168.2.4(server-1:66336)<v15>:1025
>> port 62365: TestListener processed event 2: CREATE after sleeping for 2000
>> ms: 0->[B@29004f90->EventID[192.168.2.4(client-feeder:loner):623
>> 77:a3e29f29:client-feeder;threadID=1;sequenceID=0]
>> Cache Client Updater Thread on 192.168.2.4(server-1:66336)<v15>:1025
>> port 62365: CacheClientUpdater.processMessages about to
>> verifyIfDuplicate after processing event addToMap=true
>> poolTimer-pool-2: ThreadIdToSequenceIdExpiryTask.sendPeriodicAck about
>> to ack events=[EventID[192.168.2.4(client-feeder:loner):62377:a3e29
>> f29:client-feeder;threadID=1;sequenceID=0]]
>> poolTimer-pool-2: ThreadIdToSequenceIdExpiryTask.sendPeriodicAck done
>> ack events=[EventID[192.168.2.4(client-feeder:loner):62377:a3e29
>> f29:client-feeder;threadID=1;sequenceID=0]]
>>
>>
>> Thanks,
>> Barry Oglesby
>>
>>
>> On Wed, Jan 24, 2018 at 10:30 AM, Dan Smith <ds...@pivotal.io> wrote:
>>
>>> Hi Oliver,
>>>
>>> The server won't get an acknowledgement for your event until after your
>>> cache listener completes. After the cache listener calls completes, geode
>>> adds information about the message to a collection of processed messages.
>>> Periodically it sends that collection to the server.
>>>
>>> The subscription-message-tracking-timeout parameter is a little
>>> different. The client keeps track of messages that it has seen for a
>>> certain amount of time to avoid processing a duplicate message. This
>>> timeout controls how long the client will remember messages that it has
>>> already seen.
>>>
>>> -Dan
>>>
>>> On Wed, Jan 24, 2018 at 10:00 AM, Anilkumar Gingade <agingade@pivotal.io
>>> > wrote:
>>>
>>>> >> I am wondering how Geode decide if a notification has been consumed
>>>> or not by the consumer (and decide to delete the notification from the
>>>> subscription)?
>>>> Geode relays on its highly available (with redundancy) subscription
>>>> channel to make sure, events are delivered to clients. There is no support
>>>> (or interface) at application level to let server know about the status of
>>>> the event delivery.
>>>> Once sever sends the subscription event to client; the client updates
>>>> its cache (invokes callback); and acknowledges the server; which causes
>>>> server to remove that event from its subscription queue.
>>>>
>>>> -Anil.
>>>>
>>>>
>>>> On Wed, Jan 24, 2018 at 2:53 AM, Olivier Mallassi <
>>>> olivier.mallassi@gmail.com> wrote:
>>>>
>>>>> All
>>>>>
>>>>> I have a question concerning client notification and, let's say
>>>>> "guaranteed delivery".
>>>>>
>>>>>
>>>>>
>>>>> In some of our modules, we have consumers that register interest in
>>>>> modification of keys that are present in Geode. Quite usual, we use
>>>>> the client notifications and "register Interest", and behind the
>>>>> scene, Geode creates a "subscription" that will buffer notifications for
>>>>> this consumer.
>>>>>
>>>>>
>>>>>
>>>>> I am wondering how Geode decide if a notification has been consumed or
>>>>> not by the consumer (and decide to delete the notification from the
>>>>> subscription)?
>>>>>
>>>>> To be more concrete, in a JMS world (or equivalent), this is something
>>>>> you can control with transactions or by manually acknowledging the message.
>>>>>
>>>>> Can we have the same kind of semantics? is this automatic when the
>>>>> CacheListener callbacks end? is it only relying on the
>>>>> subscription-message-tracking-timeout parameter?
>>>>>
>>>>>
>>>>> Thanks for your help.
>>>>>
>>>>>
>>>>> Olivier.
>>>>>
>>>>
>>>>
>>>
>>
>
Re: client notification & message ack
Posted by Olivier Mallassi <ol...@gmail.com>.
gentlemen, thank you.
I did not think about activating finest log levels. sorry about this.
On Wed, Jan 24, 2018 at 8:38 PM, Barry Oglesby <bo...@pivotal.io> wrote:
> What Anil and Dan said is true for durable clients, but for non-durable
> clients, the event can potentially be acked before the event is processed
> on the client. The CacheClientUpdater processMessages method invokes
> verifyIfDuplicate both before and after the processing of the event. That
> method takes a boolean whether or not to add the event id to the map of
> events to be acked. In the non-durable case, the event is added to the map
> in the first verifyIfDuplicate call before the event is processed. In the
> durable case, the event is added to the map in the second call after the
> event is processed.
>
> I added some logging to show the different behavior:
>
> Non-durable Case:
>
> In the non-durable case, you can see the event being acked by the
> poolTimer-pool-2 thread before it has been processed by the Cache Client
> Updater Thread.
>
> Cache Client Updater Thread on 192.168.2.4(server-1:66257)<v13>:1025
> port 62309: CacheClientUpdater.processMessages about to verifyIfDuplicate
> before processing event addToMap=true
> Cache Client Updater Thread on 192.168.2.4(server-1:66257)<v13>:1025
> port 62309: TestListener about to sleep for 2000ms before processing event
> 1: CREATE->0->[B@6883047e->EventID[192.168.2.4(client-
> feeder:loner):62321:22179c29:client-feeder;threadID=1;sequenceID=0]
> poolTimer-pool-2: ThreadIdToSequenceIdExpiryTask.sendPeriodicAck about to
> ack events=[EventID[192.168.2.4(client-feeder:loner):62321:
> 22179c29:client-feeder;threadID=1;sequenceID=0]]
> poolTimer-pool-2: ThreadIdToSequenceIdExpiryTask.sendPeriodicAck done ack
> events=[EventID[192.168.2.4(client-feeder:loner):62321:
> 22179c29:client-feeder;threadID=1;sequenceID=0]]
> Cache Client Updater Thread on 192.168.2.4(server-1:66257)<v13>:1025
> port 62309: TestListener processed event 2: CREATE after sleeping for 2000
> ms: 0->[B@6883047e->EventID[192.168.2.4(client-feeder:loner):
> 62321:22179c29:client-feeder;threadID=1;sequenceID=0]
>
> Durable Case:
>
> In the durable case, you can see the event being acked by the
> poolTimer-pool-2 thread after it has been processed by the Cache Client
> Updater Thread.
>
> Cache Client Updater Thread on 192.168.2.4(server-1:66336)<v15>:1025
> port 62365: CacheClientUpdater.processMessages about to verifyIfDuplicate
> before processing event addToMap=false
> Cache Client Updater Thread on 192.168.2.4(server-1:66336)<v15>:1025
> port 62365: TestListener about to sleep for 2000ms before processing event
> 1: CREATE->0->[B@29004f90->EventID[192.168.2.4(client-
> feeder:loner):62377:a3e29f29:client-feeder;threadID=1;sequenceID=0]
> Cache Client Updater Thread on 192.168.2.4(server-1:66336)<v15>:1025
> port 62365: TestListener processed event 2: CREATE after sleeping for 2000
> ms: 0->[B@29004f90->EventID[192.168.2.4(client-feeder:loner):
> 62377:a3e29f29:client-feeder;threadID=1;sequenceID=0]
> Cache Client Updater Thread on 192.168.2.4(server-1:66336)<v15>:1025
> port 62365: CacheClientUpdater.processMessages about to verifyIfDuplicate
> after processing event addToMap=true
> poolTimer-pool-2: ThreadIdToSequenceIdExpiryTask.sendPeriodicAck about to
> ack events=[EventID[192.168.2.4(client-feeder:loner):62377:
> a3e29f29:client-feeder;threadID=1;sequenceID=0]]
> poolTimer-pool-2: ThreadIdToSequenceIdExpiryTask.sendPeriodicAck done ack
> events=[EventID[192.168.2.4(client-feeder:loner):62377:
> a3e29f29:client-feeder;threadID=1;sequenceID=0]]
>
>
> Thanks,
> Barry Oglesby
>
>
> On Wed, Jan 24, 2018 at 10:30 AM, Dan Smith <ds...@pivotal.io> wrote:
>
>> Hi Oliver,
>>
>> The server won't get an acknowledgement for your event until after your
>> cache listener completes. After the cache listener calls completes, geode
>> adds information about the message to a collection of processed messages.
>> Periodically it sends that collection to the server.
>>
>> The subscription-message-tracking-timeout parameter is a little
>> different. The client keeps track of messages that it has seen for a
>> certain amount of time to avoid processing a duplicate message. This
>> timeout controls how long the client will remember messages that it has
>> already seen.
>>
>> -Dan
>>
>> On Wed, Jan 24, 2018 at 10:00 AM, Anilkumar Gingade <ag...@pivotal.io>
>> wrote:
>>
>>> >> I am wondering how Geode decide if a notification has been consumed
>>> or not by the consumer (and decide to delete the notification from the
>>> subscription)?
>>> Geode relays on its highly available (with redundancy) subscription
>>> channel to make sure, events are delivered to clients. There is no support
>>> (or interface) at application level to let server know about the status of
>>> the event delivery.
>>> Once sever sends the subscription event to client; the client updates
>>> its cache (invokes callback); and acknowledges the server; which causes
>>> server to remove that event from its subscription queue.
>>>
>>> -Anil.
>>>
>>>
>>> On Wed, Jan 24, 2018 at 2:53 AM, Olivier Mallassi <
>>> olivier.mallassi@gmail.com> wrote:
>>>
>>>> All
>>>>
>>>> I have a question concerning client notification and, let's say
>>>> "guaranteed delivery".
>>>>
>>>>
>>>>
>>>> In some of our modules, we have consumers that register interest in
>>>> modification of keys that are present in Geode. Quite usual, we use
>>>> the client notifications and "register Interest", and behind the
>>>> scene, Geode creates a "subscription" that will buffer notifications for
>>>> this consumer.
>>>>
>>>>
>>>>
>>>> I am wondering how Geode decide if a notification has been consumed or
>>>> not by the consumer (and decide to delete the notification from the
>>>> subscription)?
>>>>
>>>> To be more concrete, in a JMS world (or equivalent), this is something
>>>> you can control with transactions or by manually acknowledging the message.
>>>>
>>>> Can we have the same kind of semantics? is this automatic when the
>>>> CacheListener callbacks end? is it only relying on the
>>>> subscription-message-tracking-timeout parameter?
>>>>
>>>>
>>>> Thanks for your help.
>>>>
>>>>
>>>> Olivier.
>>>>
>>>
>>>
>>
>
Re: client notification & message ack
Posted by Barry Oglesby <bo...@pivotal.io>.
What Anil and Dan said is true for durable clients, but for non-durable
clients, the event can potentially be acked before the event is processed
on the client. The CacheClientUpdater processMessages method invokes
verifyIfDuplicate both before and after the processing of the event. That
method takes a boolean whether or not to add the event id to the map of
events to be acked. In the non-durable case, the event is added to the map
in the first verifyIfDuplicate call before the event is processed. In the
durable case, the event is added to the map in the second call after the
event is processed.
I added some logging to show the different behavior:
Non-durable Case:
In the non-durable case, you can see the event being acked by the
poolTimer-pool-2 thread before it has been processed by the Cache Client
Updater Thread.
Cache Client Updater Thread on 192.168.2.4(server-1:66257)<v13>:1025 port
62309: CacheClientUpdater.processMessages about to verifyIfDuplicate before
processing event addToMap=true
Cache Client Updater Thread on 192.168.2.4(server-1:66257)<v13>:1025 port
62309: TestListener about to sleep for 2000ms before processing event 1:
CREATE->0->[B@6883047e-
>EventID[192.168.2.4(client-feeder:loner):62321:22179c29:client-feeder;threadID=1;sequenceID=0]
poolTimer-pool-2: ThreadIdToSequenceIdExpiryTask.sendPeriodicAck about to
ack
events=[EventID[192.168.2.4(client-feeder:loner):62321:22179c29:client-feeder;threadID=1;sequenceID=0]]
poolTimer-pool-2: ThreadIdToSequenceIdExpiryTask.sendPeriodicAck done ack
events=[EventID[192.168.2.4(client-feeder:loner):62321:22179c29:client-feeder;threadID=1;sequenceID=0]]
Cache Client Updater Thread on 192.168.2.4(server-1:66257)<v13>:1025 port
62309: TestListener processed event 2: CREATE after sleeping for 2000 ms:
0->[B@6883047e-
>EventID[192.168.2.4(client-feeder:loner):62321:22179c29:client-feeder;threadID=1;sequenceID=0]
Durable Case:
In the durable case, you can see the event being acked by the
poolTimer-pool-2 thread after it has been processed by the Cache Client
Updater Thread.
Cache Client Updater Thread on 192.168.2.4(server-1:66336)<v15>:1025 port
62365: CacheClientUpdater.processMessages about to verifyIfDuplicate before
processing event addToMap=false
Cache Client Updater Thread on 192.168.2.4(server-1:66336)<v15>:1025 port
62365: TestListener about to sleep for 2000ms before processing event 1:
CREATE->0->[B@29004f90-
>EventID[192.168.2.4(client-feeder:loner):62377:a3e29f29:client-feeder;threadID=1;sequenceID=0]
Cache Client Updater Thread on 192.168.2.4(server-1:66336)<v15>:1025 port
62365: TestListener processed event 2: CREATE after sleeping for 2000 ms:
0->[B@29004f90-
>EventID[192.168.2.4(client-feeder:loner):62377:a3e29f29:client-feeder;threadID=1;sequenceID=0]
Cache Client Updater Thread on 192.168.2.4(server-1:66336)<v15>:1025 port
62365: CacheClientUpdater.processMessages about to verifyIfDuplicate after
processing event addToMap=true
poolTimer-pool-2: ThreadIdToSequenceIdExpiryTask.sendPeriodicAck about to
ack
events=[EventID[192.168.2.4(client-feeder:loner):62377:a3e29f29:client-feeder;threadID=1;sequenceID=0]]
poolTimer-pool-2: ThreadIdToSequenceIdExpiryTask.sendPeriodicAck done ack
events=[EventID[192.168.2.4(client-feeder:loner):62377:a3e29f29:client-feeder;threadID=1;sequenceID=0]]
Thanks,
Barry Oglesby
On Wed, Jan 24, 2018 at 10:30 AM, Dan Smith <ds...@pivotal.io> wrote:
> Hi Oliver,
>
> The server won't get an acknowledgement for your event until after your
> cache listener completes. After the cache listener calls completes, geode
> adds information about the message to a collection of processed messages.
> Periodically it sends that collection to the server.
>
> The subscription-message-tracking-timeout parameter is a little
> different. The client keeps track of messages that it has seen for a
> certain amount of time to avoid processing a duplicate message. This
> timeout controls how long the client will remember messages that it has
> already seen.
>
> -Dan
>
> On Wed, Jan 24, 2018 at 10:00 AM, Anilkumar Gingade <ag...@pivotal.io>
> wrote:
>
>> >> I am wondering how Geode decide if a notification has been consumed or
>> not by the consumer (and decide to delete the notification from the
>> subscription)?
>> Geode relays on its highly available (with redundancy) subscription
>> channel to make sure, events are delivered to clients. There is no support
>> (or interface) at application level to let server know about the status of
>> the event delivery.
>> Once sever sends the subscription event to client; the client updates its
>> cache (invokes callback); and acknowledges the server; which causes server
>> to remove that event from its subscription queue.
>>
>> -Anil.
>>
>>
>> On Wed, Jan 24, 2018 at 2:53 AM, Olivier Mallassi <
>> olivier.mallassi@gmail.com> wrote:
>>
>>> All
>>>
>>> I have a question concerning client notification and, let's say
>>> "guaranteed delivery".
>>>
>>>
>>>
>>> In some of our modules, we have consumers that register interest in
>>> modification of keys that are present in Geode. Quite usual, we use the
>>> client notifications and "register Interest", and behind the scene,
>>> Geode creates a "subscription" that will buffer notifications for this
>>> consumer.
>>>
>>>
>>>
>>> I am wondering how Geode decide if a notification has been consumed or
>>> not by the consumer (and decide to delete the notification from the
>>> subscription)?
>>>
>>> To be more concrete, in a JMS world (or equivalent), this is something
>>> you can control with transactions or by manually acknowledging the message.
>>>
>>> Can we have the same kind of semantics? is this automatic when the
>>> CacheListener callbacks end? is it only relying on the
>>> subscription-message-tracking-timeout parameter?
>>>
>>>
>>> Thanks for your help.
>>>
>>>
>>> Olivier.
>>>
>>
>>
>
Re: client notification & message ack
Posted by Dan Smith <ds...@pivotal.io>.
Hi Oliver,
The server won't get an acknowledgement for your event until after your
cache listener completes. After the cache listener calls completes, geode
adds information about the message to a collection of processed messages.
Periodically it sends that collection to the server.
The subscription-message-tracking-timeout parameter is a little different.
The client keeps track of messages that it has seen for a certain amount of
time to avoid processing a duplicate message. This timeout controls how
long the client will remember messages that it has already seen.
-Dan
On Wed, Jan 24, 2018 at 10:00 AM, Anilkumar Gingade <ag...@pivotal.io>
wrote:
> >> I am wondering how Geode decide if a notification has been consumed or
> not by the consumer (and decide to delete the notification from the
> subscription)?
> Geode relays on its highly available (with redundancy) subscription
> channel to make sure, events are delivered to clients. There is no support
> (or interface) at application level to let server know about the status of
> the event delivery.
> Once sever sends the subscription event to client; the client updates its
> cache (invokes callback); and acknowledges the server; which causes server
> to remove that event from its subscription queue.
>
> -Anil.
>
>
> On Wed, Jan 24, 2018 at 2:53 AM, Olivier Mallassi <
> olivier.mallassi@gmail.com> wrote:
>
>> All
>>
>> I have a question concerning client notification and, let's say
>> "guaranteed delivery".
>>
>>
>>
>> In some of our modules, we have consumers that register interest in
>> modification of keys that are present in Geode. Quite usual, we use the
>> client notifications and "register Interest", and behind the scene,
>> Geode creates a "subscription" that will buffer notifications for this
>> consumer.
>>
>>
>>
>> I am wondering how Geode decide if a notification has been consumed or
>> not by the consumer (and decide to delete the notification from the
>> subscription)?
>>
>> To be more concrete, in a JMS world (or equivalent), this is something
>> you can control with transactions or by manually acknowledging the message.
>>
>> Can we have the same kind of semantics? is this automatic when the
>> CacheListener callbacks end? is it only relying on the
>> subscription-message-tracking-timeout parameter?
>>
>>
>> Thanks for your help.
>>
>>
>> Olivier.
>>
>
>
Re: client notification & message ack
Posted by Anilkumar Gingade <ag...@pivotal.io>.
>> I am wondering how Geode decide if a notification has been consumed or
not by the consumer (and decide to delete the notification from the
subscription)?
Geode relays on its highly available (with redundancy) subscription channel
to make sure, events are delivered to clients. There is no support (or
interface) at application level to let server know about the status of the
event delivery.
Once sever sends the subscription event to client; the client updates its
cache (invokes callback); and acknowledges the server; which causes server
to remove that event from its subscription queue.
-Anil.
On Wed, Jan 24, 2018 at 2:53 AM, Olivier Mallassi <
olivier.mallassi@gmail.com> wrote:
> All
>
> I have a question concerning client notification and, let's say
> "guaranteed delivery".
>
>
>
> In some of our modules, we have consumers that register interest in
> modification of keys that are present in Geode. Quite usual, we use the
> client notifications and "register Interest", and behind the scene, Geode
> creates a "subscription" that will buffer notifications for this consumer.
>
>
>
> I am wondering how Geode decide if a notification has been consumed or not
> by the consumer (and decide to delete the notification from the
> subscription)?
>
> To be more concrete, in a JMS world (or equivalent), this is something you
> can control with transactions or by manually acknowledging the message.
>
> Can we have the same kind of semantics? is this automatic when the
> CacheListener callbacks end? is it only relying on the
> subscription-message-tracking-timeout parameter?
>
>
> Thanks for your help.
>
>
> Olivier.
>