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. C On Tue, May 8, 2012 at 1:22 AM, Narayanan A R < [email protected]> wrote: > Hi, > > 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. > > Regards, > ARN >
