This is a very interesting topic! I have two questions: - Why do you think that TTL shouldn't be tied to a session? - Does the TTL information get replicated? It sounds somewhat expensive if each heartbeat needs to be replicated.
Also somewhat related, Yisheng worked on a ZooKeeper-like service with http frontend, and we had a good discussion about session tracking: https://github.com/zk1931/jzab/issues/88 https://github.com/zk1931/pulsefs/blob/master/SPEC.md On Wed, Apr 8, 2015 at 12:09 PM, Camille Fournier <[email protected]> wrote: > All, > > I've been doing a bit of research on etcd as part of work for an upcoming > talk, and it has gotten me thinking about what it would take to create an > http version of ZK for certain operations. For many operations you could > put an http proxy in front of ZK to translate, even implementing the > "long-poll-style" watch operation to some extent. But it would be very hard > to do a temporary node via a proxy without a lot of proxy failover > complexity. > > As a bit of background, if you want to do an "ephemeral" node in etcd, you > basically create a key with a TTL. Unless the key is updated with a new > TTL, the key will auto-expire when the TTL is reached. Now, I have a lot of > thoughts about this (seems like you have to implement heartbeats via http > to truly mimic ephemeral nodes which may not be as simple as all this http > sounds), but I do think that if there is appetite for easy http access for > consensus systems we should at least take the time to think about what it > would take for us to provide this. In particular, I think we'd have to make > it possible to create a node with a TTL that is not tied to a particular > session. > > Curious to see if anyone has any thoughts on this. It seems like a bit of a > shame that ZK, which is a good battle-tested system, is frequently being > passed-over these days because of the complexity of clients, and the fact > that it is really pretty damn hard to do a client impl in certain languages > (Ruby is the notable one I've heard). > > Best, > C
