-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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][metadata] Set revalidateAfterReconnection true for certain failures #17664
[fix][metadata] Set revalidateAfterReconnection true for certain failures #17664
Conversation
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.
Great catch! It was definitely a mistake :/
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.
Nice catch! An additional test would be nice too.
Thanks for confirming! |
I can look at adding a test tomorrow. |
I think this bug may cause forget to invalidate |
@@ -196,6 +196,7 @@ synchronized void lockWasInvalidated() { | |||
// We failed to revalidate the lock due to connectivity issue |
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.
Plus, I think we also need to handle LockBusyException
here that throws by doRevalidate
method, which can avoid forgetting to complete expiredFuture
.
…ures (apache#17664) (cherry picked from commit c40c7ee)
…est !188) Squash merge branch 'release_2.8.1.4_fix_metadata' into 'release-2.8.1.4' Fixes #<xyz> ### Motivation chery pick了三个PR: PIP-45: Handle session events and invalidations from single thread (apache#12184) [fix][metadata] Set revalidateAfterReconnection true for certain failures apache#17664 [fix][metadata] Cleanup state when lock revalidation gets LockBusyException apache#17700 TAPD: --story=881235137
Motivation
In reading through the
ResourceLockImpl
, I noticed thatrevalidateAfterReconnection
is alwaysfalse
. This seems like an oversight. It was introduced in #11886.Modifications
revalidateAfterReconnection = true;
when there is a failure during lock validation.Verifying this change
I am not sure that this change will actually affect anything. In recently looking through the reconnection lo logs, I noticed the following two get logged together:
These logs relate to the following:
pulsar/pulsar-metadata/src/main/java/org/apache/pulsar/metadata/coordination/impl/LockManagerImpl.java
Lines 125 to 136 in 12ca27f
Note that the changes in this PR will affect how
lock.revalidateIfNeededAfterReconnection()
will run, but if the lock is going to be revalidated in a subsequent call because there is always another ZK notification that triggers thelock.revalidate(lock.getValue())
, then I am not sure that this PR is important. I'll continue looking into this.Documentation
doc-not-needed