-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Lock resource cleanup on member left #5601
Conversation
for (LockStoreImpl lockStore : container.getLockStores()) { | ||
releaseLock(uuid, container, lockStore); | ||
} | ||
private void releaseLocksOf(final String uuid) { |
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.
perhaps releaseLocksFrom? or releaseLockedOwnedBy?
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.
ok, renaming to releaseLocksOwnedBy
.
I don't see any tests added. We need to have some in place to verify if the behavior works correctly. |
If you can add some tests, I'm fine with merging it. |
Problem is, this is to fix a race between cleanup operation and lock operation. I'll try to write a stress test to create the issue but I'm not sure if I ever will be able to. |
Finally I'm able to reproduce the race with a custom lock operation: 16b6d86 |
…d on related partition threads, otherwise it can miss previously enqueued or being executed lock operations. So, this race can cause infinitely hanging locks. - Lock cleanup operation should check owner-uuid during its execution in partition thread to avoid race.
verify |
1 similar comment
verify |
Extracted from #5246