curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cammckenzie <...@git.apache.org>
Subject [GitHub] curator pull request: Curator 110
Date Fri, 13 Jun 2014 00:28:58 GMT
Github user cammckenzie commented on a diff in the pull request:

    https://github.com/apache/curator/pull/9#discussion_r13734392
  
    --- Diff: curator-framework/src/main/java/org/apache/curator/framework/CuratorFramework.java
---
    @@ -210,4 +213,28 @@
          * @param watcher the watcher
          */
         public void clearWatcherReferences(Watcher watcher);
    +    
    +    /**
    +     * Get the current connection state. The connection state will have a value of 0
until
    +     * the first connection related event is received.
    +     * @return The current connection state, or null if it is unknown 
    +     */
    +    public ConnectionState getCurrentConnectionState();
    +    
    +    /**
    +     * Block until a connection to ZooKeeper is available or the maxWaitTime has been
exceeded
    +     * @param maxWaitTime The maximum wait time. Specify a value <= 0 to wait indefinitely
    +     * @param units The time units for the maximum wait time.
    +     * @return True if connection has been established, false otherwise.
    +     * @throws InterruptedException If interrupted while waiting
    +     */
    +    public boolean blockUntilConnected(int maxWaitTime, TimeUnit units) throws InterruptedException;
    --- End diff --
    
    I just thought it's nicer to give control to the caller as to how long they want to wait
for rather than being bound to the connection timeout. So, you would prefer if I exposed a
blockUntilConnected() method on the CuratorZookeeperClient that takes a timeout, and then
refactor the current blockUntilConnectedOrTimedOut to call that with the connection timeout?
The only issue with this is that the current implementation of blockUntilConnectedOrTimedOut
is implemented with 1 second sleeps, so the best granularity as far as timeouts you're going
to get is a full second. This was partly why I implemented it via a connection state listener
in the CuratorFramework. It just seemed cleaner than sitting in a loop sleeping for a second
and then checking the state. I don't think that the connection state listeners are available
from the CuratorZookeeperClient though.


---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message