On Aug 21, 2012, at 1:41 PM, Jordan Zimmerman <[email protected]> wrote:
> Note, though, that Curator does more than what the FAQ describes for killing > the session. Ah, perhaps I'm misreading the Java code. It looks like it operates in the FAQ manner except it adds a watch for a non-existent node so that it can register a watcher for when it gets the next event... which is *assumed* to be a session being lost. The sessionLostWatch will get triggered for any session event, including a connection loss. I don't see anywhere that the original client is watched specifically to see that it has gotten a EXPIRED_SESSION_STATE event. In the error I described originally, the first client *will* get its connection dropped, but will not actually be expired. If I was only watching for any event, and not specifically an expired session state, then my tests would appear to work. I mainly program in Python, so its likely I'm missing something in how the Java ZK client or Curator works. Can you explain the technique here a little more? Cheers, Ben
