[jira] [Commented] (CURATOR-320) Discovery reregister triggered even if retry policy suceeds. Connection looping condition.

["Jordan Zimmerman (JIRA)" <ji...@apache.org>]

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

Jordan Zimmerman commented on CURATOR-320:
------------------------------------------

A pull request with a fix would be appreciated.

> Discovery reregister triggered even if retry policy suceeds. Connection looping condition.
> ------------------------------------------------------------------------------------------
>
>                 Key: CURATOR-320
>                 URL: https://issues.apache.org/jira/browse/CURATOR-320
>             Project: Apache Curator
>          Issue Type: Bug
>          Components: Client, Framework
>    Affects Versions: TBD, 2.10.0
>         Environment: 3 server Quorum running on individual AWS boxes.
> Session timeout set to 1-2 min on most clients.
>            Reporter: Running Fly
>             Fix For: TBD
>
>
>     ServiceDiscoveryImpl.reRegisterServices() can be trigger  on ConnectionState events: RECONNECTED and CONNECTED. Causing the reRegisterServices() method to be run on ConnectionStateManager thread. If a connection drops while running reRegisterServices() it will be recovered by the retry policy. However the ConnectionState SUSPENDED followed by RECONNECTED events will be queued but not fired until reRegisterServices() completes(ConnectionStateManager Thread fires these events but is in use). When it does complete the RECONNECTED event in the queue will fire and reRegisterServices() will rerun.
>     When zookeeper's server connection is interrupted all of the clients will simultaneously call reRegisterServices(). This overloads the server with requests causing connections to timeout and reset. Thus queuing up more RECONNECTED events. This state can persist indefinitely.
>     Because the reRegisterServices() will most likely receive a NodeExistsException. It deletes and recreates the node. Effectively causing the services to thrash up and down. Wreaking havoc on our service dependency chain. 



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