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
GEODE-9269: Make the lock holding has the same order. #6470
Conversation
* When handling TXLockService, always trying to acquire destroy read lock before getting the synchronized batchLocks. * If destroy read lock is not acuried, thread will wait until the grantor is destoryed.
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.
A few typos and test cleanup suggestions. Also, the order in which we take the lock and synchronize is the same as the order in which we release the lock and exit the synchronized block. I'm wondering if it might be better to exit the synchronized block first, then release the lock.
geode-core/src/main/java/org/apache/geode/distributed/internal/locks/DLockGrantor.java
Outdated
Show resolved
Hide resolved
geode-core/src/main/java/org/apache/geode/distributed/internal/locks/DLockGrantor.java
Outdated
Show resolved
Hide resolved
geode-core/src/main/java/org/apache/geode/distributed/internal/locks/DLockGrantor.java
Outdated
Show resolved
Hide resolved
geode-core/src/main/java/org/apache/geode/distributed/internal/locks/DLockGrantor.java
Outdated
Show resolved
Hide resolved
|
||
@Before | ||
public void setup() { | ||
dLockService = mock(DLockService.class, RETURNS_DEEP_STUBS); | ||
DistributionManager distributionManager = mock(DistributionManager.class); | ||
when(dLockService.getDistributionManager()).thenReturn(distributionManager); | ||
when(dLockService.getDLockLessorDepartureHandler()) |
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.
This is addition not necessary, as dLockService
was created using RETURNS_DEEP_STUBS
, so calling any method on it will return a mocked class. In fact, none of the mocking in this setup()
method is necessary other than:
dLockService = mock(DLockService.class, RETURNS_DEEP_STUBS);
grantor = DLockGrantor.createGrantor(dLockService, 1);
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 thought the RETURNS_DEEP_STUBS should do the trick, but the test runs failed:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/StressNewTestOpenJDK11/builds/1902
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.
Oh, weird. That must be something to do with how StressNewTest runs things in parallel.
geode-core/src/test/java/org/apache/geode/distributed/internal/locks/DLockGrantorTest.java
Outdated
Show resolved
Hide resolved
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.
Since you are changing the order we do the readLock and the sync, you should also change the order they are released. Right after you have acquired the read lock you should have the try/finally that has the finally release that read lock. Inside that try block you would have the sync block. Doing it this way makes more sense and allows the code to be refactored (for example you could extra the sync blocks into their own methods). So unless you have a good reason for not have the releases match the acquires, I think you should change them to match.
geode-core/src/main/java/org/apache/geode/distributed/internal/locks/DLockGrantor.java
Outdated
Show resolved
Hide resolved
geode-core/src/main/java/org/apache/geode/distributed/internal/locks/DLockGrantor.java
Outdated
Show resolved
Hide resolved
geode-core/src/main/java/org/apache/geode/distributed/internal/locks/DLockGrantor.java
Outdated
Show resolved
Hide resolved
geode-core/src/main/java/org/apache/geode/distributed/internal/locks/DLockGrantor.java
Outdated
Show resolved
Hide resolved
* When handling TXLockService, always trying to acquire destroy read lock before getting the synchronized batchLocks. * If destroy read lock is not acquired, thread will wait until the grantor is destroyed. (cherry picked from commit 235cd1b)
* When handling TXLockService, always trying to acquire destroy read lock before getting the synchronized batchLocks. * If destroy read lock is not acquired, thread will wait until the grantor is destroyed. (cherry picked from commit 235cd1b)
before getting the synchronized batchLocks.
is destoryed.
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:
Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?
Has your PR been rebased against the latest commit within the target branch (typically
develop
)?Is your initial contribution a single, squashed commit?
Does
gradlew build
run cleanly?Have you written or updated unit tests to verify your changes?
If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
Note:
Please ensure that once the PR is submitted, check Concourse for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to dev@geode.apache.org.