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]<mailto:[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
