[
https://issues.apache.org/jira/browse/CURATOR-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963384#comment-15963384
]
Andy Sloane edited comment on CURATOR-229 at 4/10/17 8:35 PM:
--------------------------------------------------------------
Actually I take that back; a possible workaround from the client side is this:
{code}
client.getUnhandledErrorListenable().addListener((message, e) -> {
throw new RuntimeException(message, e);
});
{code}
edit: no, the thrown exception here will also just be printed and not cause the
app to exit, so you have to flip some sort of flag in the callback which your
main app watches instead.
was (Author: asloane):
Actually I take that back; a possible workaround from the client side is this:
{code}
client.getUnhandledErrorListenable().addListener((message, e) -> {
throw new RuntimeException(message, e);
});
{code}
> 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)
