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 <[email protected]> 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 <[email protected]> > 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 < >> [email protected]> 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. >>> >> >> >
