curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jordan Zimmerman (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Deleted] (CURATOR-125) ConnectionStateListener is confused by READ_ONLY state
Date Mon, 28 Jul 2014 19:51:38 GMT

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

Jordan Zimmerman updated CURATOR-125:
-------------------------------------

    Comment: was deleted

(was: GitHub user dragonsinth opened a pull request:

    https://github.com/apache/curator/pull/22

    CURATOR-125: Fix race condition in CuratorFrameworkImpl.close()

    

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/dragonsinth/curator CURATOR-125

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/curator/pull/22.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #22
    
----
commit e3b93f221b2a43c93d71a0f51510fc5f83b51968
Author: Scott Blum <scottb@squareup.com>
Date:   2014-07-28T18:10:37Z

    CURATOR-125: Fix race condition in CuratorFrameworkImpl.close()

----
)

> 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)

Mime
View raw message