[
https://issues.apache.org/jira/browse/ZOOKEEPER-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Kamphuis updated ZOOKEEPER-2107:
---------------------------------------
Attachment: ZOOKEEPER-2107.patch
fixed formatting, and other comments.
> 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
> Assignee: Robert Kamphuis
> Fix For: 3.5.1, 3.6.0
>
> Attachments: ZOOKEEPER-2107.patch,
> 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)
