[
https://issues.apache.org/jira/browse/HADOOP-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797148#action_12797148
]
Steve Loughran commented on HADOOP-3457:
----------------------------------------
There are no tests here because you'd need to wait for the client to enter the
loop and then try and interrupt it. This is a race condition unless we added
some externally visible synchronisation point to the client in which it
notified objects waiting on it that it was about to do exactly that. I could do
that, it would give us a nice test that would work reliably everywhere, but it
would slightly change the semantics of the class. A new feature that people
might start to use.
> IPC.Client retry delay could be made configurable
> -------------------------------------------------
>
> Key: HADOOP-3457
> URL: https://issues.apache.org/jira/browse/HADOOP-3457
> Project: Hadoop Common
> Issue Type: Improvement
> Components: ipc
> Affects Versions: 0.20.2, 0.21.0, 0.22.0
> Reporter: Steve Loughran
> Assignee: Steve Loughran
> Priority: Minor
> Fix For: 0.22.0
>
> Attachments: HADOOP-3457.patch, HADOOP-3457.patch, HADOOP-3457.patch
>
>
> The delay of ipc.Client.handleConnectionFailure() that causes the client to
> block and wait is hard coded at 1 second; any interruption of the thread is
> treated as a shortening of the delay.
> // otherwise back off and retry
> try {
> Thread.sleep(1000);
> } catch (InterruptedException ignored) {}
>
> 1. this delay could be configurable; different clients may wish to retry
> more/less often. or at a slightly different rate than their peers.
> 2. interrupting the thread may imply the client has been requested to
> terminate -this could be handled by declaring failure early, rather than
> continuing to retry until the retry count is exceeded.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
