You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@curator.apache.org by Benjamin Jaton <bj...@radiantlogic.com> on 2014/07/15 23:08:36 UTC
Curator connection states
Hello,
When I have a 3 nodes ZooKeeper ensemble with 2 down and my read-only flag
is set on the curator client, here is what I see:
// initial connection:
ZOOKEEPER state change: CONNECTEDREADONLY
CURATOR state change: CONNECTED
// a second node comes up
ZOOKEEPER state change: CONNECTED
CURATOR state change: SUSPENDED
CURATOR state change: RECONNECTED
// that second node goes down again
ZOOKEEPER state change: CONNECTEDREADONLY
CURATOR state change: SUSPENDED
CURATOR state change: READ_ONLY
1) Shouldn't we have a READ_ONLY state initially? How can I know if the
connection is read only?
2) Why do we have the SUSPENDED states in between?
Thanks
Re: Curator connection states
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Ah - I missed that part. I think that might be a bug. Please open an issue and, if possible, provide a test case and PR.
-JZ
On July 16, 2014 at 6:15:22 PM, Benjamin Jaton (bjaton@radiantlogic.com) wrote:
So isn't there a problem at the beginning where zookeeper shows a CONNECTEDREADONLY state and curator shows CONNECTED?
On Wed, Jul 16, 2014 at 8:26 AM, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
1) Shouldn't we have a READ_ONLY state initially? How can I know if the connection is read only?
2) Why do we have the SUSPENDED states in between?
The connection state changes are based on the actual connection. When a connection is lost, Curator goes to SUSPENDED. Curator will report READ_ONLY only when the ZooKeeper instance returns Watcher.Event.KeeperState.ConnectedReadOnly to the main Watcher.
-JZ
On July 15, 2014 at 4:09:05 PM, Benjamin Jaton (bjaton@radiantlogic.com) wrote:
Hello,
When I have a 3 nodes ZooKeeper ensemble with 2 down and my read-only flag is set on the curator client, here is what I see:
// initial connection:
ZOOKEEPER state change: CONNECTEDREADONLY
CURATOR state change: CONNECTED
// a second node comes up
ZOOKEEPER state change: CONNECTED
CURATOR state change: SUSPENDED
CURATOR state change: RECONNECTED
// that second node goes down again
ZOOKEEPER state change: CONNECTEDREADONLY
CURATOR state change: SUSPENDED
CURATOR state change: READ_ONLY
1) Shouldn't we have a READ_ONLY state initially? How can I know if the connection is read only?
2) Why do we have the SUSPENDED states in between?
Thanks
Re: Curator connection states
Posted by Benjamin Jaton <bj...@radiantlogic.com>.
So isn't there a problem at the beginning where zookeeper shows a
CONNECTEDREADONLY state and curator shows CONNECTED?
On Wed, Jul 16, 2014 at 8:26 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> 1) Shouldn't we have a READ_ONLY state initially? How can I know if the
> connection is read only?
> 2) Why do we have the SUSPENDED states in between?
>
> The connection state changes are based on the actual connection. When a
> connection is lost, Curator goes to SUSPENDED. Curator will report
> READ_ONLY only when the ZooKeeper instance
> returns Watcher.Event.KeeperState.ConnectedReadOnly to the main Watcher.
>
> -JZ
>
> On July 15, 2014 at 4:09:05 PM, Benjamin Jaton (bjaton@radiantlogic.com)
> wrote:
>
> Hello,
>
> When I have a 3 nodes ZooKeeper ensemble with 2 down and my read-only flag
> is set on the curator client, here is what I see:
>
> // initial connection:
> ZOOKEEPER state change: CONNECTEDREADONLY
> CURATOR state change: CONNECTED
>
> // a second node comes up
> ZOOKEEPER state change: CONNECTED
> CURATOR state change: SUSPENDED
> CURATOR state change: RECONNECTED
>
> // that second node goes down again
> ZOOKEEPER state change: CONNECTEDREADONLY
> CURATOR state change: SUSPENDED
> CURATOR state change: READ_ONLY
>
> 1) Shouldn't we have a READ_ONLY state initially? How can I know if the
> connection is read only?
> 2) Why do we have the SUSPENDED states in between?
>
> Thanks
>
>
Re: Curator connection states
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
1) Shouldn't we have a READ_ONLY state initially? How can I know if the connection is read only?
2) Why do we have the SUSPENDED states in between?
The connection state changes are based on the actual connection. When a connection is lost, Curator goes to SUSPENDED. Curator will report READ_ONLY only when the ZooKeeper instance returns Watcher.Event.KeeperState.ConnectedReadOnly to the main Watcher.
-JZ
On July 15, 2014 at 4:09:05 PM, Benjamin Jaton (bjaton@radiantlogic.com) wrote:
Hello,
When I have a 3 nodes ZooKeeper ensemble with 2 down and my read-only flag is set on the curator client, here is what I see:
// initial connection:
ZOOKEEPER state change: CONNECTEDREADONLY
CURATOR state change: CONNECTED
// a second node comes up
ZOOKEEPER state change: CONNECTED
CURATOR state change: SUSPENDED
CURATOR state change: RECONNECTED
// that second node goes down again
ZOOKEEPER state change: CONNECTEDREADONLY
CURATOR state change: SUSPENDED
CURATOR state change: READ_ONLY
1) Shouldn't we have a READ_ONLY state initially? How can I know if the connection is read only?
2) Why do we have the SUSPENDED states in between?
Thanks