How does this work if the connection to ZK is lost for an extended period of time? Depending on your retry behaviour, it appears to give up retrying before the connection is re-established and the watch isn't set. I can't see how PersistentEphemeralNode is handling this situation, is there some trick I am missing?
Shaun ________________________________ From: Jordan Zimmerman [[email protected]] Sent: Wednesday, November 13, 2013 12:16 AM To: [email protected] Subject: Re: how to properly recreate ephemeral nodes and reset watches after a session expiry Have a look at PersistentEphemeralNode. It does this. -Jordan On Nov 11, 2013, at 11:20 PM, Senecal, Shaun | Shaun | BDD <[email protected]<mailto:[email protected]>> wrote: Hi, I have some code that needs to be able to recreate ephemeral nodes and reset watches after a session expiry. The approach currently taken is to keep track of all nodes that need to be recreated and all watches that need to be reset, then use a ConnectionStateListener to trigger the recovery process when a RECONNECTED event is received after a LOST event. It has been a painful process getting this to work, because I want the logic to be able to survive issues that occur DURING the recovery process as well. While the current implementation seems to be working, I'm left feeling that there has to be a better way to do this. What is the "best practice" approach? I came across this link (https://listserv.netflix.com/pipermail/curator-users/2012-June/000068.html) implying that you shouldn't recreate ephemeral nodes in a ConnectionStateListener, and instead should add a watch to each node which recreates the node when NodeDeleted or Expired is received. I have tested this solution and it appears to work. The only place I see this method getting really complicated is if I need to set watches (ie getData()) on ephemeral nodes which I want to be reset after an expiry since I would need to worry about ensuring the ephemeral node is recreated before attempting to reset the watch. Is this considered the best practice? Thanks, Shaun
