-
Notifications
You must be signed in to change notification settings - Fork 217
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 ConcurrentModification exception in Workflow Garbage Collection #741
Conversation
In workflow Garbage collection, there is possbility that we see ConcurrentMod exception while looping through the context. This commit fixes this issue.
bd655d5
to
0848259
Compare
1d5a284
to
db44ab0
Compare
db44ab0
to
0c4f575
Compare
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.
Thank you!
This PR is ready to be merged, approved by @narendly. Final commit message: Body: |
…pache#741) In workflow Garbage collection, there is possibility that we encounter ConcurrentMod exception while looping through the workflow contexts. This commit fixes this issue by adding a try-catch.
…pache#741) In workflow Garbage collection, there is possibility that we encounter ConcurrentMod exception while looping through the workflow contexts. This commit fixes this issue by adding a try-catch.
…pache#741) In workflow Garbage collection, there is possibility that we encounter ConcurrentMod exception while looping through the workflow contexts. This commit fixes this issue by adding a try-catch.
Issues
Fixes ConcurrentModificationException for the TaskGarbageCollectionStage #738
Description
Here are some details about my PR, including screenshots of any UI changes:
In workflow Garbage collection, there is possibility that we see ConcurrentMod exception
while looping through the contexts. The reason behind this exception is that the contexts can be modified using other thread (i.e. controller's main thread or other Garbage Collection threads). This commit fixes this issue by first making a copy of the contexts and then leveraging try catch to avoid such exceptions.
The following is the result of the "mvn test" command on the appropriate module:
[ERROR] Tests run: 1083, Failures: 1, Errors: 0, Skipped: 2, Time elapsed: 4,194.441 s <<< FAILURE! - in TestSuite
[ERROR] testSubscribeDataChange(org.apache.helix.manager.zk.TestZKWatch) Time elapsed: 0.023 s <<< FAILURE!
java.lang.AssertionError: expected:<0> but was:<1>
at org.apache.helix.manager.zk.TestZKWatch.testSubscribeDataChange(TestZKWatch.java:81)
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] TestZKWatch.testSubscribeDataChange:81 expected:<0> but was:<1>
[INFO]
[ERROR] Tests run: 1083, Failures: 1, Errors: 0, Skipped: 2
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:09 h
[INFO] Finished at: 2020-02-10T13:27:31-08:00
[INFO] ------------------------------------------------------------------------
mvn test -Dtest="TestZKWatch" result:
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.918 s - in org.apache.helix.manager.zk.TestZKWatch
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.069 s
[INFO] Finished at: 2020-02-10T13:27:54-08:00
[INFO] ------------------------------------------------------------------------
Commits
Code Quality