hadoop-zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Hunt (JIRA)" <j...@apache.org>
Subject [jira] Commented: (ZOOKEEPER-63) Race condition in client close() operation
Date Wed, 06 Aug 2008 19:28:44 GMT

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620396#action_12620396

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 state. 

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.

View raw message