You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When an ephemeral node is deleted in ZooKeeper, the node's parent directory's Pzxid (last modified child revision) and CVersion (number of changes to children) fields are bumped. However, since zetcd relies on etcd leases for ephemeral node deletion, there is no way to update these fields atomically when the lease is lost and the node is deleted. Working around this with a single lease per zketcd server and emulating per-connection TTLs is infeasible since sessions may have both a short TTL and a long TTL; the server's lease would either be too short or too long.
A possible solution is to extend mvccpb.KeyValue to include a lease transaction:
The lease_txn field holds a serialization of etcdserverpb.TxnRequest ; it is an opaque bytes type to avoid circular dependency between mvccpb and etcdserverpb. If the key's lease expires, the key's lease is set to 0 (for cases where deleting the key is undesirable) and lease_txn is committed. If lease_txn is nil, the key is deleted like it is now, which is a special case of the proposed lease_txn behavior.
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.
This came up in relation to etcd-io/zetcd#88
When an ephemeral node is deleted in ZooKeeper, the node's parent directory's
Pzxid
(last modified child revision) andCVersion
(number of changes to children) fields are bumped. However, since zetcd relies on etcd leases for ephemeral node deletion, there is no way to update these fields atomically when the lease is lost and the node is deleted. Working around this with a single lease per zketcd server and emulating per-connection TTLs is infeasible since sessions may have both a short TTL and a long TTL; the server's lease would either be too short or too long.A possible solution is to extend
mvccpb.KeyValue
to include a lease transaction:The
lease_txn
field holds a serialization ofetcdserverpb.TxnRequest
; it is an opaquebytes
type to avoid circular dependency between mvccpb and etcdserverpb. If the key's lease expires, the key's lease is set to 0 (for cases where deleting the key is undesirable) andlease_txn
is committed. Iflease_txn
is nil, the key is deleted like it is now, which is a special case of the proposedlease_txn
behavior.The text was updated successfully, but these errors were encountered: