> In our case, it wouldn’t throw any exception because it had gone past
> “creating lock nodes” and was blocked on wait(), which would only then be
> interrupted when curator watcher notified on previous sequence node delete
> event.
So, you're using the version of acquire() without a timeout?
A few more things...
> Based on our initial analysis and few test runs, we saw that Curator
> acquire() method acquires the lock based on “about to be deleted lock node of
> previous session”. Explanation : Ephemeral node created by previous session
> was still seen by client that reconnected