[
https://issues.apache.org/jira/browse/CURATOR-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16639550#comment-16639550
]
Sam Weston commented on CURATOR-229:
------------------------------------
I made a Java version of [~igstan]'s code and it mostly resolved my issue but
ZOOKEEPER-2184 caused me problems if the IP of my Zookeeper nodes changed.
In 2.12, if I pull in Zookeeper 3.4.13 which fixes ZOOKEEPER-2184 instead of
3.4.8, it changes the exception to UnresolvedAddressException and I don't seem
to need the new ZookeeperFactory anymore.
So I just did an exclusion for Zookeeper for all of my curator dependencies and
then pulled in Zookeeper 3.4.13 with the same exclusions as in the Curator pom:
https://github.com/apache/curator/blob/apache-curator-2.12.0/pom.xml
> No retry on DNS lookup failure
> ------------------------------
>
> Key: CURATOR-229
> URL: https://issues.apache.org/jira/browse/CURATOR-229
> Project: Apache Curator
> Issue Type: Bug
> Components: Framework
> Affects Versions: 2.7.0
> Reporter: Michael Putters
> Priority: Major
>
> Our environment is setup so that host names (rather than IP addresses) are
> used when registering services.
> When disconnecting a node from the network, it will attempt to reconnect and
> - in order to do this - attempts to resolve a host name, which fails (since
> we have no network connectivity and a DNS server is used).
> It appears this type of exception is not retryable, and the node simply gives
> up and never reconnects, even when the network connectivity is back.
> Is this the expected behavior? Is there any way to configure Curator so that
> this type of exception is retryable? I had a look at
> {{CuratorFrameworkImpl.java}} around line 768 but there doesn't seem to be
> anything configurable.
> If this is not the expected behavior (or if it is but you don't mind making
> it configurable), I should be able to provide a patch via a pull request.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
