[
https://issues.apache.org/jira/browse/CURATOR-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14075259#comment-14075259
]
Benjamin Jaton edited comment on CURATOR-125 at 7/26/14 4:22 AM:
-----------------------------------------------------------------
I recreated everything from the trunk version of ZooKeeper and Curator.
I could reproduce the problem described above right away using the Curator API.
I tried to mimic my test case with the ZooKeeper API, basically I created a
client with Watcher, and I did a .exists with Watcher as well, but I couldn't
reproduce the behavior (flickering of states)
At this point I don't know the Curator API enough to bridge the gap and prove
that it comes from Curator or ZooKeeper.
There is a problem somewhere though.
was (Author: benjamin.jaton):
I recreated everything from the trunk version of ZooKeeper and Curator.
I could reproduce the problem described above right away using the Curator API.
I tried to mimic my test case with the ZooKeeper API, basically I created a
client with Watcher, and I did a .exists with Watcher as well, but I couldn't
reproduce the behavior (flickering of states)
At this point I don't know the Curator API enough to bridge the gap and prove
that it comes prove Curator or ZooKeeper.
There is a problem somewhere though.
> ConnectionStateListener is confused by READ_ONLY state
> ------------------------------------------------------
>
> Key: CURATOR-125
> URL: https://issues.apache.org/jira/browse/CURATOR-125
> Project: Apache Curator
> Issue Type: Bug
> Components: Client
> Affects Versions: 2.6.0
> Environment: Ubuntu 12.04
> 3 ZK with readonlymode.enabled
> Reporter: Benjamin Jaton
> Attachments: Test.java
>
>
> To reproduce:
> - have a 3 nodes ZK ensemble with readonlymode.enabled
> - shut down 2 of the 3 ZK servers ( we start in read only mode)
> Then create a piece of code (see Test.java attached):
> - a curator client (keep the timeout reasonably short)
> - a NodeCache listener on '/'
> - a separate ZooKeeper client
> -> the connection goes into READ_ONLY/ConnectedReadOnly as expected
> - start another ZooKeeper
> -> the connection goes into SUSPENDED/Disconnected, then
> CONNECTED/SyncConnected, fine.
> - stop one of the 2 ZooKeeper alive
> -> the connection goes:
> ZOOKEEPER STATE: Disconnected
> CURATOR STATE: SUSPENDED
> ZOOKEEPER STATE: ConnectedReadOnly
> CURATOR STATE: READ_ONLY
> CURATOR STATE: SUSPENDED
> CURATOR STATE: READ_ONLY
> CURATOR STATE: SUSPENDED
> CURATOR STATE: READ_ONLY
> So it's flaky. Sometimes it doesn't switch back and forth, sometimes twice
> only, sometimes a lot more.
> Depending on the timeout on the client, it might take more time to appear.
> I attached a sample code that would reproduce it in 20-30 seconds.
> Note that the problem may ultimately be on the ZooKeeper side but at that
> point I just don't know.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
