james strachan commented on ZOOKEEPER-63:

I wonder if I've seen this too - I can reliably get a hung test when trying to 
close a client (though the server is still up at the point if the hang).

I'm thinking the close() method should not wait() forever on the disconnect 
packet, just a closeTimeout length - say a few seconds. Afterall blocking and 
forcing a reconnect just to redeliver the disconnect packet seems a bit silly - 
when the server has to deal with clients which just have their sockets fail 
anyway :)

> Race condition in client close() operation
> ------------------------------------------
>                 Key: ZOOKEEPER-63
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-63
>             Project: Zookeeper
>          Issue Type: Bug
>          Components: java client
>            Reporter: Patrick Hunt
>            Assignee: Benjamin Reed
> There is a race condition in the java close operation on ZooKeeper.java.
> Client is sending a disconnect request to the server. Server will close any 
> open connections with the client when it receives this. If the client has not 
> yet shutdown it's subthreads (event/send threads for example) these threads 
> may consider the condition an error. We see this alot in the tests where the 
> clients output error logs because they are unaware that a disconnection has 
> been requested by the client.
> Ben mentioned: perhaps we just have to change state to closed (on client) 
> before sending disconnect request.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to