zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yan Xu <...@jxu.me>
Subject Re: Zookeeper C client fail to deliver a session event
Date Mon, 28 Apr 2014 19:03:01 GMT
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  


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