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