-
Notifications
You must be signed in to change notification settings - Fork 25
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
Fix interrupt handling #272
Conversation
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 you need to do the same in ApiClient.java?
@@ -95,7 +95,7 @@ public class {{.PascalName}}API { | |||
try { | |||
Thread.sleep((long) (sleep * 1000L + Math.random() * 1000)); | |||
} catch (InterruptedException e) { | |||
Thread.currentThread().interrupt(); | |||
throw new DatabricksException("Current thread was interrupted", 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.
You have to call Thread.currentThread().interrupt()
to reset the interrupted bit so that callers will know that this thread was interrupted and can handle such a change.
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.
I thought that we are already throwing an exception which should be handled by the callers. But I think it won't harm to reset the flag. Just in case someone suppresses the exception, it will still flag the thread as interrupted.
Thanks for catching this. I'll update it as well. |
cc4f56c
to
bf74ba0
Compare
Head branch was pushed to by a user without write access
03e2351
to
bba0619
Compare
bba0619
to
88d8b6a
Compare
Changes
Current implementation does not work well when client interrupts a thread where SDK code is running. Once interrupted, the logic continues to run till the timeout (default 20mins) without sleeping at all. Each time thread.sleep is called, it throws interrupt exception and this results in calling the status API continuously without delay.
The PR is changing the handling to throw DatabricksException when the thread is interrupted so that clients can stop the processing and handle the exception as they wish.
Tests
All unit tests are successful.