curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: Curator connection states
Date Wed, 16 Jul 2014 23:18:25 GMT
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 <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


Mime
View raw message