curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Senecal, Shaun | Shaun | BDD" <shaun.sene...@mail.rakuten.com>
Subject RE: how to properly recreate ephemeral nodes and reset watches after a session expiry
Date Thu, 14 Nov 2013 06:47:04 GMT
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 [jordan@jordanzimmerman.com]
Sent: Wednesday, November 13, 2013 12:16 AM
To: user@curator.apache.org
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 <shaun.senecal@mail.rakuten.com<mailto:shaun.senecal@mail.rakuten.com>>
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


Mime
View raw message