hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Li Lu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-11398) RetryUpToMaximumTimeWithFixedSleep needs to behave more accurately
Date Tue, 14 Jul 2015 21:01:04 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-11398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14627032#comment-14627032
] 

Li Lu commented on HADOOP-11398:
--------------------------------

bq. We cannot assume t1=t2 because t2 becomes larger than t1 when there are underlying retries.
If this is the case, then only allowing retries to t1+delta_t is wrong because we may accidentally
but completely disable retry when t1 and t2 are significantly different. What we want is to
"retry for time t after an error occurred" but not to "retry for time t after the retry object
is initialized". 

> RetryUpToMaximumTimeWithFixedSleep needs to behave more accurately
> ------------------------------------------------------------------
>
>                 Key: HADOOP-11398
>                 URL: https://issues.apache.org/jira/browse/HADOOP-11398
>             Project: Hadoop Common
>          Issue Type: Bug
>            Reporter: Li Lu
>            Assignee: Li Lu
>         Attachments: HADOOP-11398-121114.patch, HADOOP-11398.002.patch
>
>
> RetryUpToMaximumTimeWithFixedSleep now inherits RetryUpToMaximumCountWithFixedSleep and
just acts as a wrapper to decide maxRetries. The current implementation uses (maxTime / sleepTime)
as the number of maxRetries. This is fine if the actual for each retry is significantly less
than the sleep time, but it becomes less accurate if each retry takes comparable amount of
time as the sleep time. The problem gets worse when there are underlying retries. 
> We may want to use timers inside RetryUpToMaximumTimeWithFixedSleep to perform accurate
timing. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message