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

Some LockRegistryLeaderInitiator improvements #8570

Conversation

artembilan
Copy link
Member

It is better to not go to the target lock provider at all if the current thread is already interrupted.

  • Check for the Thread.currentThread().isInterrupted() in the while loop and restartSelectorBecauseOfError() immediately without checking for a lock
  • Fix some other simple typos in the LockRegistryLeaderInitiator

Cherry-pick to 6.0.x

It is better to not go to the target lock provider at all
if the current thread is already interrupted.

* Check for the `Thread.currentThread().isInterrupted()` in the `while` loop
and `restartSelectorBecauseOfError()` immediately without checking for a lock
* Fix some other simple typos in the `LockRegistryLeaderInitiator`

**Cherry-pick to `6.0.x`**
@artembilan
Copy link
Member Author

Do not merge yet: looking into yielding logic which is not always OK when we just cancel the Future...

to revoke leader smoothly.
Turns out just canceling the `Future` may lead to a broken lock
where we cannot unlock it because the target lock repository may not work
with interrupted threads.
This way a new leader must wait until the lock is expired in the store
@artembilan artembilan requested a review from garyrussell March 15, 2023 13:38
@garyrussell garyrussell merged commit 8fbf75f into spring-projects:main Mar 15, 2023
garyrussell pushed a commit that referenced this pull request Mar 15, 2023
* Some `LockRegistryLeaderInitiator` improvements

It is better to not go to the target lock provider at all
if the current thread is already interrupted.

* Check for the `Thread.currentThread().isInterrupted()` in the `while` loop
and `restartSelectorBecauseOfError()` immediately without checking for a lock
* Fix some other simple typos in the `LockRegistryLeaderInitiator`

**Cherry-pick to `6.0.x`**

* * Introduce a `LeaderSelector.yielding` flag
to revoke leader smoothly.
Turns out just canceling the `Future` may lead to a broken lock
where we cannot unlock it because the target lock repository may not work
with interrupted threads.
This way a new leader must wait until the lock is expired in the store
@garyrussell
Copy link
Contributor

...and cherry-picked as 2adf334

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants