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: > 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. >>>> >>> >>> >> >
