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

JBTM-3911 Replace synchronized in favor of Reentrant Lock in LRAService joinLRA method #2293

Merged
merged 1 commit into from
Sep 11, 2024

Conversation

marcosgopen
Copy link
Member

@marcosgopen marcosgopen commented Aug 26, 2024

https://issues.redhat.com/browse/JBTM-3911

previous title was 'Remove redundant lock monitor from LRAService'

!CORE !AS_TESTS !RTS !JACOCO !XTS !QA_JTA !QA_JTS_OPENJDKORB !PERFORMANCE LRA !DB_TESTS

@marcosgopen marcosgopen requested a review from xstefank August 26, 2024 15:11
@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

import jakarta.ws.rs.core.MediaType;
import jakarta.ws.rs.core.Response;

public class LRAWithParticipantsTest {
Copy link
Collaborator

Choose a reason for hiding this comment

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

@marcosgopen this is very much like copy-paste of LRATest. Refactor it so we don't need to always change the same thing in two different classes please.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks Martin, I cleaned and refactored the test.

@@ -328,7 +328,7 @@ public int leave(URI lraId, String compensatorUrl) {
}
}

public synchronized int joinLRA(StringBuilder recoveryUrl, URI lra, long timeLimit,
public int joinLRA(StringBuilder recoveryUrl, URI lra, long timeLimit,
Copy link
Collaborator

Choose a reason for hiding this comment

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

As we discussed offline, I'm not sure what all the possible implications of removing synchronized from this method could be. I would like to hear from @mmusgrov why it was synchronized in the first place.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good idea, I put the on hold label.

Copy link
Member

Choose a reason for hiding this comment

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

@marcosgopen I added a comment to the JBTM indicating that the tests are good but I'm not convinced that removing the monitor is the correct approach. Personally I would keep the tests but withdraw the fix and work on a different fix for the lock contention, do you mind if I look into the alternate approach?

Copy link
Member Author

Choose a reason for hiding this comment

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

I updated the PR, I am still removing the synchronized but adding the ReentrantLock during the enlistment. Could you have a look at this solution @mmusgrov ?

Copy link
Member

Choose a reason for hiding this comment

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

The general technique used in the PR is a good one to break the lock contention. I did have some comments about other parts of the PR though so I have asked for changes.

@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

@marcosgopen marcosgopen removed the Hold label Sep 2, 2024
@marcosgopen marcosgopen requested a review from mmusgrov September 2, 2024 09:04
@@ -328,7 +328,7 @@ public int leave(URI lraId, String compensatorUrl) {
}
}

public synchronized int joinLRA(StringBuilder recoveryUrl, URI lra, long timeLimit,
public int joinLRA(StringBuilder recoveryUrl, URI lra, long timeLimit,
Copy link
Member

Choose a reason for hiding this comment

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

@marcosgopen I added a comment to the JBTM indicating that the tests are good but I'm not convinced that removing the monitor is the correct approach. Personally I would keep the tests but withdraw the fix and work on a different fix for the lock contention, do you mind if I look into the alternate approach?

@marcosgopen
Copy link
Member Author

That works for me @mmusgrov , I put the on hold label and I will re-adapt the PR so to keep only the test.

@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

@@ -90,7 +90,8 @@ public void lraMBean() throws Exception {

@Test
public void lraMBeanRemoval() throws Exception {
LongRunningAction lra = new LongRunningAction(new Uid());
String lraUrl = "http://localhost:8080/lra";
Copy link
Member Author

Choose a reason for hiding this comment

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

Previous way of creating the LRA was not working anymore, lraID was not initialized and therefore was causing a NullPointerException at https://github.com/jbosstm/narayana/blob/main/rts/lra/coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L107. So changing how it is initialized.

Copy link
Member

Choose a reason for hiding this comment

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

The NullPointerException path from tryLockTransaction(URI) that I observed was during the addition of tryLockTransaction needed for enlistParticipant so I expect changing this test is OK. Although the LongRunningAction(Uid) constructor is added for MBean listing, it is used here to initialize a useable LongRunningAction and so it is reasonable to change it to use one of the constructors that appear expected for that purpose.

Copy link
Member

Choose a reason for hiding this comment

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

I will take a look next week (I'm on PTO today but wanted to get this PR reviewed asap).

Copy link
Member

Choose a reason for hiding this comment

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

But don't let this comment block the PR.

Copy link
Member

@mmusgrov mmusgrov Sep 9, 2024

Choose a reason for hiding this comment

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

The constructor should only be used when loading an LRA from the ObjectStore. So after constructing the LRA the expectation is that restore_state will be called so that the URI for the LRA gets initialised. Clearly the code is brittle so it would be nice to firm it up in this area - I have raised JBTM-3919 so that we don't loose site of it.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks Mike!

@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

if (participant != null) {
participant.setCompensatorData(compensatorData);
return participant; // must have already been enlisted
long timeLimit, String compensatorData) throws UnsupportedEncodingException {
Copy link
Member

Choose a reason for hiding this comment

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

Superfluous reformatting.

@mmusgrov
Copy link
Member

@marcosgopen Will you also squash the commits prior to merging please.

@marcosgopen
Copy link
Member Author

@mmusgrov PR updated and commits squashed. Thanks for your review.
WDYT if we change the JBTM title with a more consistent one? e.g. "Replace synchronized in favor of Reentrant Lock in LRAService joinLRA method'

Copy link
Member

@mmusgrov mmusgrov left a comment

Choose a reason for hiding this comment

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

PR looks good, sorry for not explaining ERROR vs WARN logging levels more clearly.

@mmusgrov
Copy link
Member

@mmusgrov PR updated and commits squashed. Thanks for your review. WDYT if we change the JBTM title with a more consistent one? e.g. "Replace synchronized in favor of Reentrant Lock in LRAService joinLRA method'

+1 clearer titles and descriptions help a lot to ease the "cognitive burden".

@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

LRA profile tests failed (https://ci-jenkins-csb-narayana.apps.ocp-c1.prod.psi.redhat.com/job/btny-pulls-narayana/PROFILE=LRA,jdk=openJDK11,label=jnlp-agent/489/): LRA Test failed with failures in no_arq profile

@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

@marcosgopen marcosgopen changed the title JBTM-3911 Remove redundant lock monitor from LRAService JBTM-3911 Replace synchronized in favor of Reentrant Lock in LRAService joinLRA method Sep 11, 2024
@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

@jbosstm-bot
Copy link

@marcosgopen
Copy link
Member Author

LRA profile tests failed (https://ci-jenkins-csb-narayana.apps.ocp-c1.prod.psi.redhat.com/job/btny-pulls-narayana/PROFILE=LRA,jdk=openJDK11,label=jnlp-agent/489/): LRA Test failed with failures in no_arq profile

I investigated the reason of the failure and, long story short, this is not related to this PR.
However I am working on that for another issue: https://issues.redhat.com/browse/JBTM-3922.

@marcosgopen marcosgopen merged commit eb77841 into jbosstm:main Sep 11, 2024
@jbosstm-bot
Copy link

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

Successfully merging this pull request may close these issues.

5 participants