Github user cammckenzie commented on the pull request:
https://github.com/apache/curator/pull/9#issuecomment-46139081
Scratch that, I think that the reason that the CuratorZookeeperClient was
doing a spin loop was because there's a race condition with the watchers. It's
possible for the local watcher to get a 'connected' event before the
ConnectionState gets its 'connected' event. This means that when you call into
ConnectionState.isConnected() it returns false, even though we know it's
actually true.
So, while we could return the boolean based on what we know the state to
be, it's going to be inconsistent for a short period with the ConnectionState,
and this has potential for knock on consequences, even though the window of
inconsistency is short.
So, I think it's actually better to move this wait logic into the
CuratorFramework and use the ConnectionStateListener.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
