[
https://issues.apache.org/jira/browse/CURATOR-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963556#comment-15963556
]
Cameron McKenzie commented on CURATOR-229:
------------------------------------------
I don't believe there's a way of configuring Curator to modify the exceptions
that it considers retryable currently.
I'm not sure if changing Curator to retry on the UnknownHostException would do
much anyway. The exception is being thrown by the underlying ZK client. Every
time Curator tried to create a new ZK client while the hostname was
unresolvable, the error would occur.
I guess if your DNS outage is only for a short period (or you have a long retry
period defined) then it would be recoverable.
I think that possibly the best generic fix is to make the RetryLoop code have a
default set of error codes that are retryable and then allow that to be
overridden. I think that this is a bit of effort due to the way that RetryLoop
is currently accessed (statically), but I will have a look into it.
> 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
>
> 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
(v6.3.15#6346)
