-
Notifications
You must be signed in to change notification settings - Fork 541
8088343: Race condition in javafx.concurrent.Task::cancel #1769
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
8088343: Race condition in javafx.concurrent.Task::cancel #1769
Conversation
|
👋 Welcome back angorya! A progress list of the required criteria for merging this PR into |
|
@andy-goryachev-oracle This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be: You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 9 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
Webrevs
|
|
Reviewers: @kevinrushforth @arapte /reviewers 2 |
|
@kevinrushforth |
kevinrushforth
left a comment
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.
Avoiding the case where we transition from FAILED or SUCCEEDED to CANCELLED is good, and should fix the test failures (although I'll do some additional testing), but I can't help wondering if underlying problem is something else. The question I have is: how do we get into a state where Worker.State of the Task one of the completion states (FAILED or SUCCEEDED), whereas the parent FutureTask is not completed, and so enters a canceled state. You can see this by instrumenting the code and calling super.isCancelled().
I wonder if the custom service created by TestServiceFactory is causing, or contributing to, the problem?
| switch (getState()) { | ||
| case FAILED: | ||
| case SUCCEEDED: |
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.
Avoiding transitioning from a one of the completion states to canceled is a good thing. My question, though is: how did we get here? Is this masking some other problem?
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 think the variations in the test timing uncovered this issue. I don't think it's a problem with the execution of the task, but rather with the reporting of its final state.
| break; | ||
| } | ||
| }); | ||
| return rv.get(); |
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.
This is ineffective since you don't wait for the runLater to execute (and waiting could lead to deadlock, so I wouldn't recommend that). I don't think there is anything better than unconditionally returning flag when not running on the FX app thread. That's what the current code does (and is what your proposed fix will do most of the time).
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.
good point!
In this particular case, returning true from cancel() when state will not be changed is acceptable.
kevinrushforth
left a comment
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.
LGTM. I instrumented the code and after a few test runs was able to spot a couple cases where this would have failed without the fix.
arapte
left a comment
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.
LGTM... Could observe test failure without this change.
|
Thank you Kevin and Ambarish! |
|
Going to push as commit 48240da.
Your commit was automatically rebased without conflicts. |
|
@andy-goryachev-oracle Pushed as commit 48240da. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
The code should not set the
Task.statevalue toCANCELLEDif the said task is alreadySUCCEEDEDorFAILED.This is a product bug.
Added
@RepeatedTest(50)to the tests that used to fail intermittently - this made the test failed more reliably without the fix.Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jfx.git pull/1769/head:pull/1769$ git checkout pull/1769Update a local copy of the PR:
$ git checkout pull/1769$ git pull https://git.openjdk.org/jfx.git pull/1769/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 1769View PR using the GUI difftool:
$ git pr show -t 1769Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/1769.diff
Using Webrev
Link to Webrev Comment