Thanks Asad, I wasn’t expecting a session expiration but indeed ZK_CONNECTING_STATE, just didn’t seem to have received one.
Yan From: Asad Saeed [email protected] Reply: [email protected] [email protected] Date: April 25, 2014 at 11:01:41 PM To: [email protected] [email protected] Cc: [email protected] [email protected] Subject: Re: Zookeeper C client fail to deliver a session event Yan, According to your logs you did not have a session expire, but your connection was lost. You should have received a session event stating ZK_CONNECTING_STATE, when the client detected it had disconnected. I have wrapped this functionality in our own implementation of the client. When we get this event we create timer that will trigger a expiry unless ZK_CONNECTED state occurs within the expected duration of the expected session. The c client will only trigger ZK_EXPIRED_SESSION_STATE, if on reconnect the server states that the session provided is expired. Asad On Apr 25, 2014, at 1:20 PM, Raúl Gutiérrez Segalés <[email protected]> wrote: > On 25 April 2014 11:18, Raúl Gutiérrez Segalés <[email protected]> wrote: > >> On 25 April 2014 10:15, Yan Xu <[email protected]> wrote: >> >>> Hi zookeeper-user, >>> >>> When I was triaging an issue with my ZK wrapper I think I found that >>> during >>> disconnection ZK client has failed to deliver the session event to the >>> watcher (but logged it). >>> >>> The log shows: >>> >>> 2014-04-23 23:50:30,324:990(0x7f75d4ba9940):ZOO_INFO@check_events@1703: >>> initiated connection to server [<...>:2181] >>> 2014-04-23 23:50:31,603:990(0x7f75d4ba9940):ZOO_INFO@check_events@1750: >>> session establishment complete on server [<...>:2181], >>> sessionId=0x2456db1b7d32534, negotiated timeout=10000 >>> ... >>> 2014-04-23 >>> 23:50:38,925:990(0x7f75d4ba9940):ZOO_ERROR@handle_socket_error_msg@1643: >>> Socket [<...>:2181] zk retcode=-7, errno=110(Connection timed out): >>> connection to <...>:2181 timed out (exceeded timeout by 636ms) >>> 2014-04-23 23:50:38,925:990(0x7f75d4ba9940):ZOO_WARN@zookeeper_interest >>> @1557: >>> Exceeded deadline by 1842ms >>> 2014-04-23 23:50:38,925:990(0x7f75d4ba9940):ZOO_INFO@check_events@1703: >>> initiated connection to server [<...>:2181] >>> 2014-04-23 23:50:38,927:990(0x7f75d4ba9940):ZOO_INFO@check_events@1750: >>> session establishment complete on server [<...>:2181], >>> sessionId=0x2456db1b7d32534, negotiated timeout=10000 >>> >> >>> which indicates that ZK client state transitioned from CONNECTED -> >>> CONNECTING -> CONNECTED. >>> >>> But my wrapper code was expecting a watcher event with ZOO_SESSION_EVENT & >>> ZOO_CONNECTING_STATE but never got one. >>> The events for the CONNECTED state before and after the disconnection were >>> delivered. >>> >>> >> Was auth performed in the missing parts of the log? If so I guess you >> could take the first branch here: >> >> >> https://github.com/apache/zookeeper/blob/branch-3.4/src/c/src/zookeeper.c#L1224 >> >> >> thus not missing the PROCESS_SESSION_EVENT(zh, ZOO_CONNECTING_STATE) call. >> > > Meant "thus missing". Lack of coffee :-) > > I wonder if this could happen when you have an AUTH packet in-flight. > > > -rgs
