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 ([email protected]) 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 <[email protected]> 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 ([email protected]) 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
