[jira] [Resolved] (ZOOKEEPER-1126) state of zk_handle should NOT be initialized to 0 (CLOSED) in zokeeper_init. It should have a not initialized state.

["Dheeraj Agrawal (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ZOOKEEPER-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dheeraj Agrawal resolved ZOOKEEPER-1126.
----------------------------------------

    Resolution: Duplicate
      Assignee: Dheeraj Agrawal

> state of zk_handle should NOT be initialized to 0 (CLOSED) in zokeeper_init. It should have a not initialized state.
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: ZOOKEEPER-1126
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1126
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: c client
>    Affects Versions: 3.3.3
>            Reporter: Dheeraj Agrawal
>            Assignee: Dheeraj Agrawal
>
> In zoo_add_auth, we have following check.
>   2954     // [ZOOKEEPER-800] zoo_add_auth should return ZINVALIDSTATE if
>    2955     // the connection is closed.
>    2956     if (zoo_state(zh) == 0) {
>    2957         return ZINVALIDSTATE;
> when we do zookeeper_init, the state is initialized to 0 and above we check if state = 0 then throw exception.
> There is a race condition where the doIo thread is slow and has not changed the state to CONNECTING, then you end up returning back ZKINVALIDSTATE from zoo_add_auth.
> The problem is we use 0 for CLOSED state and UNINITIALIZED state. in case of uninitialized case it should let it go through.
> Is this intentional? In java we have the uninitialized state = null. 
> If not we can initialize it to some other magic number.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira