Patrick Hunt commented on ZOOKEEPER-63:

Assigning to myself - I've cleaned up the tests as part of ZOOKEEPER-111 (this 
was blocking progress on this issue). I'll dig into this issue now.

Looking at the code for zk close it seems to me that the issue is related to 
how the client send/event threads manage state. In particular these threads 
look "out/up" at the parent (zookeeper.state) rather than managing state 
internally and having operations for code  (zk client) to make changes to that 

There is a race condition in the close where sendthread thinks that the 
connection is still open (not closed) and retries the server connection rather 
than shutting down.

I will probably have to have significant changes to how send/event threads are 
managed - they need to manage their own internal state and take updates from 
zookeeper client.... we'll see.

> 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: Patrick Hunt
>         Attachments: patch_ZOOKEEPER-63.patch
> 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