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

Cam McKenzie commented on CURATOR-570:
--------------------------------------

Thanks [~ryarran], seems like it would make sense to modify Curator to have 
consistent ordering of clients. Additionally, it is probably worth 
preprocessing the connection string provided directly to Curator (rather than 
the one returned from Zookeeper), so that if Curator has been supplied 
hostnames rather than IP addresses, then we don't get the initial unnecessary 
call to updateServerList().



[~randgalt], do you know how this works on the Zookeeper side? I was just 
thinking that if the connection string provided to Curator is a list of 
hostnames, that storing them as IP addresses rather than resolving them each 
time may cause issues with load balancers etc.  If ZK resolves the hostnames to 
IP addresses anyway though, then we're just delaying the inevitable by not 
resolving the hostnames before the initial connection to ZK.

> Excessive calls to ZooKeeper.updateServerList (which can result in session 
> death)
> ---------------------------------------------------------------------------------
>
>                 Key: CURATOR-570
>                 URL: https://issues.apache.org/jira/browse/CURATOR-570
>             Project: Apache Curator
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: 4.2.0, 4.3.0
>            Reporter: Rhys Yarranton
>            Priority: Major
>
> On suspend and reconnect, Curator calls ZooKeeper.updateServerList via 
> ConnectionState.checkState --> ConnectionState.handleNewConnectionString.  In 
> addition, recipes may be triggered by this as well, and they too make calls 
> ZooKeeper.updateServerList via ConnectState.checkTimeouts --> 
> ConnectionState.handleNewConnectionString.
> This happens even though the connection string has not actually changed.
> Due to ZOOKEEPER-3825, this can cause the connection to be closed 
> immediately.  On its own this would be perceived as a glitch.  But due to the 
> Curator-induced calls, what we see is a cycle of SUSPENDED/RECONNECTED, until 
> eventually the session dies and a new session is recreated.
> Based on the source code (at time of writing), ZooKeeper.updateServerList is 
> not intended to be called frequently like this.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to