Yes, I will open a JIRA for this. Regarding my original email, it is normal that the background retry goes on for longer than the LOST event?
On Thu, Jan 15, 2015 at 2:52 PM, Jordan Zimmerman < [email protected]> wrote: > Yeah. If Curator itself can be altered to support it, please send a PR. > Even if not, send a PR as this might be useful to others. > > -JZ > > > > On January 15, 2015 at 5:51:01 PM, Benjamin Jaton ([email protected]) > wrote: > > Instead of that, I think I am going to implement a custom event for the > session loss that will be trigger either: > - sessionTimeoutMs after the last SUSPENDED event (if no RECONNECTED event > has been received) > - on a RECONNECTED event if the new session ID is different from the old > one. > > It's a little hacky but that should probably do the trick to have a timely > notification that the session has been lost. > > What do you think? > > On Thu, Jan 15, 2015 at 10:31 AM, Benjamin Jaton <[email protected]> > wrote: > >> Ah thanks for the tip, I'm definitely going to try that. >> >> On Thursday, January 15, 2015, Jordan Zimmerman < >> [email protected]> wrote: >> >>> NOTE: You can also set a main watcher that watches for session >>> expiration. >>> >>> -JZ >>> >>> >>> >>> On January 15, 2015 at 11:39:53 AM, Jordan Zimmerman ( >>> [email protected]) wrote: >>> >>> LOST was never intended to match session loss. Session loss is only >>> detected by ZooKeeper once the connection is re-established. >>> >>> -JZ >>> >>> >
