[
https://issues.apache.org/jira/browse/ZOOKEEPER-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15440114#comment-15440114
]
Michael Han commented on ZOOKEEPER-2519:
----------------------------------------
The patch looks like malformatted, can't be applied to branch-3.4. [Reference
on generating
patch|https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute]
{code}
zh->fd = -1;
zh->connect_index++;
if (!is_unrecoverable(zh)) {
-| zh->state = 0;
+| zh->state = ZOO_CONNECTING_STATE;
}
if (process_async(zh->outstanding_sync)) {
process_completions(zh);
}
{code}
Instead of using {{ZOO_CONNECTING_STATE}}, why not using
{{ZOO_NOTCONNECTED_STATE}}, given the reconnect attempt hasn't been made at
this point yet? Later, in zookeeper_interest when reconnecting attempt being
made the state will be set to {{ZOO_CONNECTING_STATE}}.
> zh->state should not be 0 while handle is active
> ------------------------------------------------
>
> Key: ZOOKEEPER-2519
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2519
> Project: ZooKeeper
> Issue Type: Bug
> Components: c client
> Affects Versions: 3.4.6
> Reporter: Andrew Grasso
> Attachments: ZOOKEEPER-2519.patch
>
>
> 0 does not correspond to any of the defined states for the zookeeper handle,
> so a client should not expect to see this value. But in the function
> {{handle_error}}, we set {{zh->state = 0}}, which a client may then see.
> Instead, we should set our state to be {{ZOO_CONNECTING_STATE}}.
> At some point the code moved away from 0 as a valid state and introduced the
> defined states. This broke the fix to ZOOKEEPER-800, which checks if state is
> 0 to know if the handle has been created but has not yet connected. We now
> use {{ZOO_NOTCONNECTED_STATE}} to mean this, so the check for this in
> {{zoo_add_auth}} must be changed.
> We saw this error in 3.4.6, but I believe it remains present in trunk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
