-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HBASE-24396 : RetryCounter#sleepUntilNextRetry and ThrottledInputStre… #1765
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -513,11 +513,7 @@ private <T> T executeWithRetries(final Callable<T> callable) { | |
throw new RuntimeException("retries exhausted", e); | ||
} | ||
} | ||
try { | ||
retryCounter.sleepUntilNextRetry(); | ||
} catch (InterruptedException e) { | ||
throw new RuntimeException(e); | ||
} | ||
retryCounter.sleepUntilNextRetry(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Here also we are changing the behave. Previously throw RTE when interrupted. But now this is been changed Main thing is even if interrupted, the RetryCounter will make sure the thread been slept for the specified time (Which might not be really wanted some times) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I believe the purpose of retryCounter.sleepUntilNextRetry() should be uninterrupted sleep because RetryCounter is mainly being used by retries with sleeps and retries with different backoff policies. In such scenario, RetryCounter being a library should not ideally throw InterruptedException even if sleep is interrupted because it is being retried by clients to achieve certain tasks. |
||
} | ||
} | ||
|
||
|
@@ -535,11 +531,7 @@ private void waitFor(final Callable<Boolean> predicate) { | |
throw new RuntimeException("retries exhausted", e); | ||
} | ||
} | ||
try { | ||
retryCounter.sleepUntilNextRetry(); | ||
} catch (InterruptedException e) { | ||
throw new RuntimeException(e); | ||
} | ||
retryCounter.sleepUntilNextRetry(); | ||
} | ||
} | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -130,11 +130,7 @@ void triggerFlushInPrimaryRegion(final HRegion region) throws IOException { | |
ServerRegionReplicaUtil.getRegionInfoForDefaultReplica(region.getRegionInfo()) | ||
.getRegionNameAsString(), | ||
region.getRegionInfo().getRegionNameAsString(), counter.getAttemptTimes(), e); | ||
try { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You did not get what I was saying I believe. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok got it. Yes this example makes sense. Are you saying that similar to this one, all the other places also need to handle Interruptions and there is no need to have uninterrupted sleep during client side retries? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I did not check all places.. Most of the places where the RetryCounter is being used is in test I can see. But within RetryCounter we should not change. Tomorrow some other code path might use it too. IMO we can just keep the code as is. Let the calling part handle the InterruptedException the way they want. we can not generalise it. So just close this Jira Viraj There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Okk just saw that many places are in asynchronously getting executed in separate threads from main thread and if this is how interruptions were planned to be handled, it's fine. No need to make change. |
||
counter.sleepUntilNextRetry(); | ||
} catch (InterruptedException e1) { | ||
throw new InterruptedIOException(e1.getMessage()); | ||
} | ||
counter.sleepUntilNextRetry(); | ||
continue; | ||
} | ||
|
||
|
@@ -188,11 +184,7 @@ void triggerFlushInPrimaryRegion(final HRegion region) throws IOException { | |
break; | ||
} | ||
} | ||
try { | ||
counter.sleepUntilNextRetry(); | ||
} catch (InterruptedException e) { | ||
throw new InterruptedIOException(e.getMessage()); | ||
} | ||
counter.sleepUntilNextRetry(); | ||
} | ||
region.setReadsEnabled(true); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to this jira? When during the throttle sleep, if we interrupt this thread, it would have come out of sleep by throwing an IOE as per the current code. But a call to sleepUninterruptibly will make sure the thread is in sleep state for that much time. The interrupt might be for a genuine case to stop the running thread. Now this change will make it such that even if been interrupted, the thread will still continue to be executed!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, throttle()'s purpose should ideally be to throttle without any interruption.