-
Notifications
You must be signed in to change notification settings - Fork 9.2k
HDDS-1672. Improve locking in OzoneManager. #1016
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
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.
nit: if acquireLock can return true , the you can write acquiredBucketLock = acquireLock, just eliminates 2 lines of code
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.
Fixed it..
|
💔 -1 overall
This message was automatically generated. |
|
💔 -1 overall
This message was automatically generated. |
|
💔 -1 overall
This message was automatically generated. |
241369a to
61274f1
Compare
|
💔 -1 overall
This message was automatically generated. |
| metadataManager.getLock().acquireVolumeLock(volumeName); | ||
| metadataManager.getLock().acquireBucketLock(volumeName, bucketName); | ||
| boolean acquiredBucketLock = false; | ||
| metadataManager.getLock().acquireLock(VOLUME_LOCK, volumeName); |
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.
There is a subtle bug here. We either need to assume that acquireLock cannot fail, or assume that it can fail.
If it cannot fail: Then the finally is simple, you can release bucket and volume lock.
if it can fail: Then it is possible the acquire volume lock is going to fail -- and there is no handling -- I am presuming that it will throw up into the calling unction and there is some sort of a handler there ? if that is the case, what will it throw ? I am not sure it can fail -- @arp7 comments?
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.
We have no option but to assume that it can fail for two reasons:
- Because of the following check:
public void acquireVolumeLock(String volume) {
// Calling thread should not hold any bucket lock.
// You can take an Volume while holding S3 bucket lock, since
// semantically an S3 bucket maps to the ozone volume. So we check here
// only if ozone bucket lock is taken.
if (hasAnyBucketLock()) {
throw new RuntimeException(
"Thread '" + Thread.currentThread().getName() +
"' cannot acquire volume lock while holding bucket lock(s).");
}
- The wrapped call to
lockPool.borrowObject()inLockManager#lockdeclares that it can throwException. So that covers pretty much any exception under the earth.
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.
If lock acquire fails, we get RunTimeException from underlying LockManager.
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.
Looked at this further. Failure to get volume lock is fine here. It is up to the caller to release their resources when the stack is unwound.
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.
I haven't looked at the entire patch however I am +1 on this particular point.
anuengineer
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.
I am not sure that lock calls can fail. So we might have some spurious calls. But it is okay.
|
I reached out to @arp7 offline, he is fine with proceeding forward. |
|
Test failures are not related to this patch. |
|
Thank You @anuengineer for the review. |
…erface. (apache#1016) * Move StartpointVisitor to SystemAdmin.
Changes in this PR: