-
Notifications
You must be signed in to change notification settings - Fork 944
ARTEMIS-4197 mitigate races w/various config changes #6080
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
Conversation
|
The full test-suite is green on this. |
brusdev
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.
This solution is very robust, the only drawback I can find is the possibility of multiple records for the same item when the deletion fails. Those leacked records could be detected/removed when the journal is loaded to mitigate this issue.
4c0bfb6 to
5ba24a1
Compare
|
@brusdev, I refactored this a bit to avoid orphaned records. |
|
Full test-suite looks good on this. |
|
@jbertram can you rebase your branch to resolve the conflicts? |
5ba24a1 to
74a4dc4
Compare
This commit mitigates a number of different potential race conditions involving configuration changes. Consider the storeAddressSetting method in o.a.a.a.c.p.i.j.AbstractJournalStorageManager. It mutates mapPersistedAddressSettings twice - once to delete an entry and once to put an entry. If another thread executes the recoverAddressSettings method in between these two operations it will not contain the record that is being stored. This same race condition exists for a number of different maps. This commit mitigates the race condition by ensuring that the relevant map is mutated only once (i.e. via put). This commit also refactors a number of methods to avoid duplicated code. There are no tests associated with this change since there's no deterministic way to induce the race condition. It relies on static analysis and existing tests to validate the fix and detect regressions.
74a4dc4 to
015f5b8
Compare
|
@brusdev, done! |
brusdev
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.
@jbertram nice work! I'm running the full test suite again just for the sake of safety before merging it.
This commit mitigates a number of different potential race conditions involving configuration changes. Consider the storeAddressSetting method in o.a.a.a.c.p.i.j.AbstractJournalStorageManager. It mutates mapPersistedAddressSettings twice - once to delete an entry and once to put an entry. If another thread executes the recoverAddressSettings method in between these two operations it will not contain the record that is being stored. This same race condition exists for a number of different maps.
This commit mitigates the race condition by ensuring that the relevant map is mutated only once (i.e. via put).
This commit also refactors a number of methods to avoid duplicated code.
There are no tests associated with this change since there's no deterministic way to induce the race condition. It relies on static analysis and existing tests to validate the fix and detect regressions.