Skip to content
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

Merged
merged 2 commits into from
Jul 14, 2015
Merged

Conversation

mdogan
Copy link
Contributor

@mdogan mdogan commented Jun 26, 2015

  • Lock cleanup task submitted when a member is left should be executed 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.

Extracted from #5246

@mdogan mdogan added this to the 3.6 milestone Jun 26, 2015
@pveentjer pveentjer changed the title Fixes regarding lock resource cleanup on member left Lock resource cleanup on member left Jun 29, 2015
for (LockStoreImpl lockStore : container.getLockStores()) {
releaseLock(uuid, container, lockStore);
}
private void releaseLocksOf(final String uuid) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perhaps releaseLocksFrom? or releaseLockedOwnedBy?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, renaming to releaseLocksOwnedBy.

@pveentjer
Copy link
Contributor

I don't see any tests added. We need to have some in place to verify if the behavior works correctly.

@pveentjer
Copy link
Contributor

If you can add some tests, I'm fine with merging it.

@mdogan
Copy link
Contributor Author

mdogan commented Jun 30, 2015

I don't see any tests added. We need to have some in place to verify if the behavior works correctly.

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.

@mdogan
Copy link
Contributor Author

mdogan commented Jul 7, 2015

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.
@mdogan
Copy link
Contributor Author

mdogan commented Jul 8, 2015

verify

1 similar comment
@mdogan
Copy link
Contributor Author

mdogan commented Jul 10, 2015

verify

@pveentjer pveentjer merged commit 16b6d86 into hazelcast:master Jul 14, 2015
@mdogan mdogan deleted the lock-cleanup branch July 14, 2015 06:57
@mmedenjak mmedenjak added the Source: Internal PR or issue was opened by an employee label Apr 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Source: Internal PR or issue was opened by an employee Team: Core Type: Defect
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants