[
https://issues.apache.org/jira/browse/ZOOKEEPER-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104594#comment-13104594
]
Matthias Spycher commented on ZOOKEEPER-961:
--------------------------------------------
Agreed, this line isn't related to the fix. It slipped in - I should probably
have separated the changes into two separate patches.
It has to do with honoring the close() as early as possible. Note that if
state.isAlive() returns false, the while loop ends, so we shouldn't issue
warnings about attempting to reconnect. I don't see how it changes the
isConnected logic. My assumption here is that we shouldn't allow a transition
from CLOSE or AUTH_FAILED back to CONNECTING.
> Watch recovery after disconnection when connection string contains a prefix
> ---------------------------------------------------------------------------
>
> Key: ZOOKEEPER-961
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-961
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
> Affects Versions: 3.3.1
> Environment: Windows 32 bits
> Reporter: pmpm47
> Assignee: Matthias Spycher
> Priority: Critical
> Fix For: 3.3.4, 3.4.0
>
> Attachments: ZOOKEEPER-961.patch, ZOOKEEPER-961.patch,
> ZOOKEEPER-961.patch, ZOOKEEPER-961b.patch, ZOOKEEPER-961b.patch
>
>
> Let's say you're using connection string "127.0.0.1:2182/foo".
> 1) put a childrenchanged watch on relative / (that is, on absolute path /foo)
> 2) stop the zk server
> 3) start the zk server
> 4) at this point, the client recovers the connection, and should have put
> back a watch on relative path /, but instead the client puts a watch on the
> *absolute* path /
> - if some other client adds or removes a node under /foo, nothing will happen
> - if some other client adds or removes a node under /, then you will get an
> error from the zk client library (string operation error)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
