In what you're describing, your service creates ephemeral nodes on behalf
of its clients, and has to track the clients liveness. You're redoing a lot
of the logic ZK would handle for you if you had your clients talk directly
to ZK, but you can certainly reimplement that logic if you want. I think
this is a less-than-ideal system design but if you have a system where
stateful connections don't make sense it might be the best you can do.
I would recommend spending some time with the ZK documentation and a
highlighter, it sounds like you might want to design something fairly
complex and it's useful to really understand the system well before you
start on such a task.
On Tue, May 8, 2012 at 1:22 AM, Narayanan A R <
[EMAIL PROTECTED]> wrote:
> Does ZK support ephermal node creation for stateless clients. Anyone has
> dealt with similar requests? For instance, one or more clients would make
> REST API call to a service and it in turns creates nodes in ZK. Connections
> could be active between the service and ZK but not to the client. I am
> looking something like a client would touch a znode periodically for the
> heartbeat and if the heartbeat goes away, the nodes created by that client
> should get deleted. Is this supported?
> Similarly, I am looking for notifications for stateless clients. Basically
> registering a post pack URL for ZK to make a callback.