This repository has been archived by the owner on Oct 7, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 91
Ephemeral node deleted by connection loss prevents parent node deletion #88
Comments
I've been digging a bit, but I think the issue may be that the correlated etcd node's lifetime is tied to the lease of the entire zetcd server, and not to any particular client's connection. I haven't yet found why the ephemeral node disappears from zetcd at all, but I would guess that there's a disconnect between what zetcd is showing and what etcd has stored. I'll keep poking around. |
Nope, leases are per-connection. I think I found an unrelated ephemeral node bug, though... |
heyitsanthony
added a commit
to heyitsanthony/zetcd
that referenced
this issue
Nov 8, 2017
Ephemeral node deletion doesn't update the CVersion, so the directory will seem to have children when it doesn't after losing ephemeral nodes. Note: this fails cross-checking and etcd likely needs an API extension to get full zk compatibility. Fixes etcd-io#88
This was referenced Nov 8, 2017
Sorry for the silence, that fix does work for me. |
Hello @heyitsanthony, |
/cc @gyuho |
Just merged. Thanks! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This one's a bit weird, but basically if you create some node, and then create a sequential node within it, the node goes away on client connection loss, but the parent cannot be deleted because it thinks it isn't empty. Here's a sample (using the python kazoo library):
Basic setup:
Okay, now we can create foo, create foo/bar as ephemeral, fail to delete foo as expected, delete foo/bar, and then deleting /foo works also as expected:
Now for the weird; create /foo as before, create /foo/bar ephemeral as before, but disconnect and reconnect the client, then try to delete /foo (which appears to be empty):
Well, that was weird. /foo looks empty, but deleting it says it isn't empty. Can we fix things? Yes, re-creating /foo/bar and then explicitly deleting it lets us delete /foo again:
So, that's weird.
The text was updated successfully, but these errors were encountered: