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