yes you got it correct... a slight correction. I am trying to find a way where I can make my tree cache event handler aware that "node removed" event is coming from a persistent ephemeral node and delay any action till the point the node's curator framework gives up on rewriting the node to ZK.
On Mon, Oct 12, 2015 at 3:38 PM, Cameron McKenzie <[email protected]> wrote: > So, if I'm understanding correctly, if your application loses its > connection to ZooKeeper (or crashes), then a new instance will be started > in its place, and if the original instance reconnects then you don't want > it to try and recreate its ephemeral node? > > If that's the case, then I think that you need additional logic beyond > what a PersistentEphemeralNode is going to provide you, as you will need to > check if the node already exists on reconnection. > > On Tue, Oct 13, 2015 at 8:43 AM, Vikrant Singh < > [email protected]> wrote: > >> yeah I considered that.. but I ended up using tree cache because it gives >> me more control on the state of tree . I have some custom handlers for >> add/remove/update events. Same cache is also used for service discovery. >> >> On Mon, Oct 12, 2015 at 2:33 PM, David Kesler <[email protected]> wrote: >> >>> There’s also already a Curator service discovery extension library that >>> you can look at: >>> http://curator.apache.org/curator-x-discovery/index.html. It’s >>> basically boiling down to the same strategy of sticking an ephemeral node >>> into ZK, but with some additional convenience and functionality built on >>> top of it. >>> >>> >>> >>> *From:* Cameron McKenzie [mailto:[email protected]] >>> *Sent:* Monday, October 12, 2015 5:05 PM >>> *To:* [email protected] >>> *Subject:* Re: Persistent Ephemeral Node >>> >>> >>> >>> hey Vikrant, >>> >>> Using a persistent ephemeral node just means that your application code >>> doesn't need to worry about handling recreation of the node when it >>> reconnects to ZooKeeper after connection / session loss. >>> >>> >>> >>> If your ephemeral node should always be present whenever your >>> application instance is running, then this would be a good use case for a >>> persistent ephemeral node. >>> >>> cheers >>> >>> >>> >>> >>> >>> On Tue, Oct 13, 2015 at 6:03 AM, Vikrant Singh < >>> [email protected]> wrote: >>> >>> I have some basic question on persistent ephemeral node. >>> >>> Here is some background... >>> >>> >>> >>> We have a zoo keeper based service discovery setup. Each service >>> register itself as a ephemeral node with zookeeper.When a service go down >>> its ephemeral node is removed from zookeeper and we know that service is >>> down and we provision it again. >>> >>> At present we create plain ephemeral node. I am wondering what >>> benefit/risks we may get if move to persistent ephemeral ones. I see one >>> problem... using plane ephemeral node we can rely on state of ZK to make a >>> decision like service is down. This is because we are sure that if a node >>> get deleted with zoo keeper it will never comeback from same process. But >>> if moved to "persistent ephemeral" I guess same may not be the case. >>> >>> >>> >>> Please let me know what you think of the same. >>> >>> >>> >>> Also I would like to know what are the best scenario where one should >>> prefer using persistent ephemeral node over ephemeral node. >>> >>> >>> >>> Thanks, >>> >>> Vikrant >>> >>> >>> >> >> >
