You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2015/09/01 03:17:45 UTC

[jira] [Commented] (CURATOR-247) Extend Curator's connection state to support SESSION_LOST

    [ https://issues.apache.org/jira/browse/CURATOR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14724526#comment-14724526 ] 

ASF GitHub Bot commented on CURATOR-247:
----------------------------------------

Github user cammckenzie commented on a diff in the pull request:

    https://github.com/apache/curator/pull/97#discussion_r38377860
  
    --- Diff: curator-client/src/main/java/org/apache/curator/connection/ConnectionHandlingPolicy.java ---
    @@ -0,0 +1,72 @@
    +package org.apache.curator.connection;
    +
    +import org.apache.curator.CuratorZookeeperClient;
    +import org.apache.curator.RetryLoop;
    +import java.util.concurrent.Callable;
    +
    +/**
    + * Abstracts connection handling so that Curator can emulate it's old, pre 3.0.0
    + * handling and update to newer handling.
    + */
    +public interface ConnectionHandlingPolicy
    +{
    +    /**
    +     * Return true if this policy should behave like the pre-3.0.0 version of Curator
    +     *
    +     * @return true/false
    +     */
    +    boolean isEmulatingClassicHandling();
    +
    +    /**
    +     * Called by {@link RetryLoop#callWithRetry(CuratorZookeeperClient, Callable)} to do the work
    +     * of retrying
    +     *
    +     * @param client client
    +     * @param proc the procedure to retry
    +     * @return result
    +     * @throws Exception errors
    +     */
    +    <T> T callWithRetry(CuratorZookeeperClient client, Callable<T> proc) throws Exception;
    +
    +    enum CheckTimeoutsResult
    +    {
    +        /**
    +         * Do nothing
    +         */
    +        NOP,
    +
    +        /**
    +         * handle a new connection string
    +         */
    +        NEW_CONNECTION_STRING,
    +
    +        /**
    +         * reset/recreate the internal ZooKeeper connection
    +         */
    +        RESET_CONNECTION,
    +
    +        /**
    +         * handle a connection timeout
    +         */
    +        CONNECTION_TIMEOUT,
    +
    +        /**
    +         * handle a session timeout
    +         */
    +        SESSION_TIMEOUT
    +    }
    +
    +    /**
    +     * Check timeouts. NOTE: this method is only called when an attempt to access to the ZooKeeper instances
    +     * is made and the connection has not completed.
    +     *
    +     * @param hasNewConnectionString proc to call to check if there is a new connection string. Important: the internal state is cleared after
    +     *                               this is called so you MUST handle the new connection string if <tt>true</tt> is returned
    +     * @param connectionStartMs the epoch/ms time that the connection was first initiated
    +     * @param sessionTimeoutMs the configured session timeout in milliseconds
    --- End diff --
    
    Should this be the negotiated session timeout rather than the configured session timeout? Looking at the code that calls into this interface, it would seem that the configured timeout from the build is being used. Is that correct though? I would have thought that the negotiated timeout was what was important as it's the source of truth.


> Extend Curator's connection state to support SESSION_LOST
> ---------------------------------------------------------
>
>                 Key: CURATOR-247
>                 URL: https://issues.apache.org/jira/browse/CURATOR-247
>             Project: Apache Curator
>          Issue Type: Sub-task
>          Components: Framework
>    Affects Versions: 2.8.0
>            Reporter: Jordan Zimmerman
>            Assignee: Jordan Zimmerman
>             Fix For: 3.0.0
>
>
> Currently, Curator has a connection state for LOST that confuses users. It does _not_ mean that the session is lost. Instead it means that the retry policy has given up retrying. Introduce a new connection state that roughly corresponds to the ZooKeeper session expiring. Possibly require that clients request this support via a new new builder method in CuratorFrameworkFactory



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)