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-2982 Drive LRA participants from a separate thread #1332
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -560,8 +560,31 @@ private void endCheck(Activity activity) { | |
activity.setHow(null); | ||
activity.setArg(null); | ||
|
||
if ("wait".equals(how) && arg != null && "recovery".equals(arg)) { | ||
lraClient.getRecoveringLRAs(); | ||
if ("wait".equals(how)) { | ||
if (arg != null) { | ||
if ("recovery".equals(arg)) { | ||
/* | ||
* during end processing we delay the response by triggering a recovery scan | ||
* which tests that the coordinator can handle slow participants and is able | ||
* to tolerate recovery running when there are outstanding participant | ||
* completion calls. | ||
*/ | ||
lraClient.getRecoveringLRAs(); // run a recovery scan | ||
} else { | ||
int ms = 0; | ||
|
||
try { | ||
ms = Integer.getInteger(arg, 0); | ||
} catch (Exception ignore) { | ||
} | ||
|
||
try { | ||
Thread.sleep(ms <= 0 ? Long.MAX_VALUE : ms); // delay the end call | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would like to understand the rationalization of giving to user a way of delaying end call? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a test. The intent is to show that LRA can cope with participants that are slow in responding to the complete/compensate calls or, worse, participants that hang. See the following tests that inject problems in participant end processing: SpecIT#closeLRAWaitForRecovery There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ouch, I see. Even I was checking the package I missed that. I'm sorry, this is fine. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If I push a commit for the indentation and remove the jdwp debug comment will that fix your issues with this PR. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Notice that I also added a comment to indicate what the recovery scan is testing here. |
||
} catch (InterruptedException e) { | ||
LRALogger.logger.info("endCheck wait interrupted"); | ||
} | ||
} | ||
} | ||
} else if ("exception".equals(how)) { | ||
Exception cause = null; | ||
|
||
|
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.
do we need here this comment when the
swarm.debug.jdwp
attribute covers this?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.
What do you mean, do you want me to add an explanation of how the debugging config works?
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.
sure. I'm sorry for not being clear. I just meant that if there is declared
coordinator.debug.jdwp
with debug parameters the comment could be removed completely. The information is doubled.