[
https://issues.apache.org/jira/browse/ZOOKEEPER-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14319846#comment-14319846
]
Robert Kamphuis commented on ZOOKEEPER-2107:
--------------------------------------------
Thanks for taking a look !
While the resolveAndShuffle() will indeed redo the dns-lookups, the trouble is
that this method is only called when explicitly changing the configurations via
ZooKeeper.updateServerList()
Our usecase (trouble-case) is when any of the AWS hosted zookeeper-servers
disappears, and a replacement comes back with a different mapping of hostname
to IP address.
Unless the updateServerList() is triggered, existing running
application-servers will continue to try to connect to the now disappeared old
instance.
and I did just retest this to be sure ;)
With the patch applied, and a simple LateResolvingHostProvider provided by the
zookeeper-user, the call to next() will re-resolve whenever a new connection is
needed.
And if this is of no interest to a particular setup, one can create the
ZooKeeper with the existing default HostProvider.
The patch just offers the possibility to fix this particular use case for AWS
hosted setups (and others like it)
> zookeeper client should support custom HostProviders
> ----------------------------------------------------
>
> Key: ZOOKEEPER-2107
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2107
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client
> Affects Versions: 3.5.0
> Reporter: Robert Kamphuis
> Fix For: 3.5.1
>
> Attachments: enable-custom-hostprovider_in_zookeeper-client3.patch
>
>
> The zookeeper client currently contains a StaticHostProvider and no means to
> replace it with your own implementation of the existing HostProvider
> interface. It would be great if the zookeeper client would enable you to
> create an instance with your own implementation of the HostProvider
> interface.
> We have been testing this change with our implementation of HostProvider
> which does the name to ip lookup at the time of finding the next() server to
> connect to. In our AWS based deployments, this enables that applications can
> actually connect to swapped out zookeeper-servers which typically get a new
> ip address. With the current StaticHostProvider in practice you will need to
> restart the application to see the replaced zookeeper as the application
> continues to try to connect to the old no longer existing IP address.
> With this little change plus a straightforward implementation of the
> HostProvider interface (our LateResolvingHostProvider), we can replace the
> zookeeper servers one at a time, re-assigning the elastic ips we use for the
> zookeeper servers, and have the application servers re-connect to the
> zookeeper cluster including the replaced ones without any downtime and
> without having to rely on the elastic ips for client to zookeeper-server
> connections. The reason for not using elastic-ips in the connect-strings but
> use the names which map to the (changing) private ips is to be able to rely
> on security-groups to control access.
> While this seems very specific for AWS, this anyway seems a generic
> improvement for other deployments where the mapping from server name to IP
> address is not static.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
