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 asaeed@scalecomputing.com
Reply: user@zookeeper.apache.org user@zookeeper.apache.org
Date: April 25, 2014 at 11:01:41 PM
To: user@zookeeper.apache.org user@zookeeper.apache.org
Cc: zookeeper-user@hadoop.apache.org zookeeper-user@hadoop.apache.org
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 <rgs@itevenworks.net> wrote:
> On 25 April 2014 11:18, Raúl Gutiérrez Segalés <rgs@itevenworks.net> wrote:
>
>> On 25 April 2014 10:15, Yan Xu <yan@jxu.me> 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
|