-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
STORM-2396: setting interrupted status back before throwing a RuntimeException #1989
Conversation
@@ -134,6 +134,8 @@ | |||
import clojure.lang.Keyword; | |||
import clojure.lang.RT; | |||
|
|||
import static java.lang.Thread.currentThread; |
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.
Thread.currentThread()
is widely used so it's more readable than currentThread()
for me.
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.
Okay, will change.
@@ -356,13 +358,14 @@ public static void sleep(long millis) { | |||
try { | |||
Time.sleep(millis); | |||
} catch(InterruptedException e) { | |||
currentThread().interrupt(); |
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.
How it will collaborate with throwing RuntimeException? Are we assuming that caller catches RuntimeException? Just not clear that how it works together.
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.
Here's a suboptimal example of a loop that will never exit as intended
while(!currentThread.isInterrupted()) {
execute();
}
...
void execute() {
try {
... // RE may be thrown here
Utils.sleep(1000);
... // and here
} catch (RuntimeException e)
log.error(e);
}
}
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.
Got it. Thanks.
+1 |
1 similar comment
+1 |
As described in JIRA the interrupted flag is not set back after catching InterruptedException and wrapping it into a RuntimeException so any code dependent on checking the interrupted status will not work properly in case the RuntimeException doesn't make it up the stack.