zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <mckenzie....@gmail.com>
Subject Re: Reconnection with expired session
Date Wed, 12 Nov 2014 06:13:24 GMT
Thanks Jurgen,
It certainly opens a can of worms. I'm a committer on the Curator project,
so I was wondering if there was something we could put in there to handle
this sort of case, but I don't think that the Curator libraries are
actually getting any events to indicate this case. We would need to do
something like run a timer when we get a Disconnected event and then
destroy our current connection and recreate a fresh one if this timer
expires before reconnection.

Having said that, it's such an edge case that it's probably not worth
thinking too much about!

On Wed, Nov 12, 2014 at 4:57 PM, "Jürgen Wagner (DVT)" <
juergen.wagner@devoteam.com> wrote:

> Hello Cameron,
>   that indeed is the question. Asking for a new session is always be
> possible by simply not specifying the old session credentials, however,
> the question is whether a client can determine this condition occurred,
> as opposed to just the inability to connect to the ensemble for other
> reasons. It is possible that the Zookeeper state is different in this
> case (e.g., there may be not EXPIRED state, only DISCONNECTED).
> But even if so, would we get false positives from that test in case only
> one Zookeeper of the entire ensemble goes bezerk and it is absolutely
> correct to get that connection refused? Wouldn't that special condition
> you observed not just occur in the case of the entire ensemble being
> wiped out and reset? Wouldn't it be legitimate to expect the clients
> then go also through a full restart to recover from this grave condition
> of the coordination service?
> There is nothing graceful about the entire Zookeeper ensemble being
> deprived of its data, so the best effort to recover on the client side
> would probably to set a time limit after which the new session will be
> opened instead of further attempting to reconnect, i.e., essentially the
> client decides it is time to restart.
> I'll have a look into this. It requires some thinking and testing :-)
> Cheers,
> --Jürgen
> On 12.11.2014 06:32, Cameron McKenzie wrote:
> > Thanks for the explanation Jurgen,
> > Does the client application (using the ZK client libs) actually get a
> > notification from the ZK client code that this situation has occurred?
> i.e.
> > Would it actually be possible for an application to identify this
> situation
> > and ask for a new session?
> >
> > What I seemed to see when I was stepping through in a debugger (and what
> > the logs would imply) was that the reconnect code would just go around
> > indefinitely.
> > cheers
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message