[
https://issues.apache.org/jira/browse/HADOOP-19964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18105940#comment-18105940
]
ASF GitHub Bot commented on HADOOP-19964:
-----------------------------------------
joseluisll commented on code in PR #8682:
URL: https://github.com/apache/hadoop/pull/8682#discussion_r3813786719
##########
hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/test/GenericTestUtils.java:
##########
@@ -399,11 +399,13 @@ public static void waitFor(final Supplier<Boolean> check,
}
if (!result) {
+ // Dump now, while the threads are still hung: TimedOutTestsListener
+ // only sees the failure once the test and its teardown have unwound.
+ TimedOutTestsListener.dumpForTimeout("GenericTestUtils.waitFor");
final String exceptionErrorMsg = "Timed out waiting for condition. "
+ (org.apache.commons.lang3.StringUtils.isNotEmpty(errorMsg)
- ? "Error Message: " + errorMsg : "")
- + "\nThread diagnostics:\n" +
- TimedOutTestsListener.buildThreadDiagnosticString();
+ ? "Error Message: " + errorMsg + " " : "")
+ + TimedOutTestsListener.DUMP_PRINTED_MARKER;
Review Comment:
Fixed — dumpForTimeout returns whether it printed, and waitFor appends the
marker only then.
Checked the second half of your point too: omitting the marker can't produce
a double dump. Both paths that make shouldDump() refuse — the off switch and an
exhausted per-JVM budget — refuse identically when the listener asks, so
there's no second dump to suppress.
New cases pin the exact message in all three states: dump printed,
-Dhadoop.test.timedout.dump=false, and budget spent.
> Restore TimedOutTestsListener thread dumps on test timeout
> ----------------------------------------------------------
>
> Key: HADOOP-19964
> URL: https://issues.apache.org/jira/browse/HADOOP-19964
> Project: Hadoop Common
> Issue Type: Test
> Reporter: Jose Luis López
> Priority: Critical
> Labels: pull-request-available
>
> Goal: a test that fails on @Timeout prints a full thread dump into its
> surefire report. Today it prints nothing, and a timeout without thread state
> is undiagnosable after the fact.
>
> This is a regression. TimedOutTestsListener (HADOOP-8755, 2012) did exactly
> this until the JUnit 5 migration (HADOOP-19415 Part4) left it implementing no
> listener interface. The Surefire "listener" property that 8 poms still carry
> registers nothing.
>
> Fix:
> * Reimplement it as a JUnit Platform TestExecutionListener, auto-registered
> via META-INF/services in the hadoop-common test artifact.
> * Remove the dead "listener" property from the 8 poms.
> * -Dhadoop.test.timedout.dump=false turns it off;
> -Dhadoop.test.timedout.dump.limit (default 5) caps dumps per JVM.
>
> Covers timeouts that fail through JUnit. Does not cover Surefire's fork kill
> (forkedProcessTimeoutInSeconds), which halts the JVM and bypasses listeners.
> Complements HADOOP-19950, whose CI upload globs already capture the report
> files these dumps land in.
>
> The listener activates for every consumer of the hadoop-common test artifact,
> including HBase, Ozone, Hive and Tez: needs a release note.
>
> Test-scope only; no production code is touched.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
