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