[
https://issues.apache.org/jira/browse/CURATOR-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13715612#comment-13715612
]
Andy Grove commented on CURATOR-40:
-----------------------------------
The only thing curator could do differently is the workaround I suggested
above, where DNS resolution is attempted for each server in the connect list
and the connect string could then be re-written using IP addresses for the
valid hosts. Let's see if this can get fixed on Zookeeper first though as that
would be ideal. Thanks again.
> Curator client cannot connect after one zookeeper host shuts down on EC2
> ------------------------------------------------------------------------
>
> Key: CURATOR-40
> URL: https://issues.apache.org/jira/browse/CURATOR-40
> Project: Apache Curator
> Issue Type: Bug
> Components: Client
> Affects Versions: 2.0.1-incubating
> Environment: Ubuntu instances on Amazon EC2 using DNS host names
> Reporter: Andy Grove
> Attachments: ApacheCuratorUnknownHostTest.java
>
>
> We use DNS names on Amazon EC2 to specify Zookeeper host names. If one of the
> ZK hosts shuts down or loses network connectivity we can no longer connect
> via Curator, even though the other ZK hosts are still running and have
> quorum. The issue is specific to an UnknownHostException being thrown on DNS
> resolution when calling the start() method on CuratorZookeeperClient. The
> workaround is for us to use IP addresses rather than DNS names, but this
> isn't really workable on EC2 since IP addresses change when servers restart
> so we use Elastic IPs to ensure that the ZK hosts have fixed IP addresses.
> I have attached a unit test which demonstrates the issue and provides more
> detail in the comments.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
