[
https://issues.apache.org/jira/browse/HDFS-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18063868#comment-18063868
]
ASF GitHub Bot commented on HDFS-17869:
---------------------------------------
balodesecurity opened a new pull request, #8314:
URL: https://github.com/apache/hadoop/pull/8314
## Problem
In `QuorumJournalManager`, nine methods catch `InterruptedException` and
`TimeoutException` and rethrow as `IOException` without chaining the original
exception as the cause:
```java
} catch (InterruptedException e) {
throw new IOException("Interrupted waiting for format() response");
// ^ no
cause!
}
```
Affected methods: `format`, `hasSomeData`, `doPreUpgrade`, `doUpgrade`,
`doFinalize`, `canRollBack`, `doRollback`, `discardSegments`, `getJournalCTime`.
When these exceptions surface in logs or are caught upstream, the original
stack trace (and the interrupted thread's state) is lost entirely, making the
root cause of failures invisible during debugging.
## Fix
Pass the caught exception as the second argument to `IOException(String,
Throwable)` in all 18 affected catch blocks, preserving the full exception
chain.
## Testing
- Added
`TestQuorumJournalManagerUnit#testFormatTimeoutExceptionIsCauseChained`:
configures a QJM with a 50 ms operations timeout, makes all loggers return
futures that never resolve, calls `format()`, and asserts that the thrown
`IOException` has a `TimeoutException` as its cause.
- Test passes locally.
> Missing root exception cause in QuorumJournalManager.java
> ---------------------------------------------------------
>
> Key: HDFS-17869
> URL: https://issues.apache.org/jira/browse/HDFS-17869
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Affects Versions: 3.3.6
> Reporter: WeiLinJin
> Priority: Minor
> Labels: exception
> Attachments: HDFS-17869.patch
>
>
> Dear HDFS developers, we are developing a tool to detect exception-related
> bugs in Java. Our primary focus is on identifying issues where the caught
> exception is rethrown without propagating the original exception as the
> cause. When such errors occur, the root cause exception is swallowed,
> resulting in incomplete call stacks in error reports. This makes it hard to
> trace the origin of the exception and hinders debugging efforts.
> Version: Hadoop-3.3.6
> File: org.apache.hadoop.hdfs.qjournal.client.QuorumJournalManager
> Line: 257-261 275-279 682-686 699-703 716-720 747-753 768-772 785-791 816-822
> For example，Line: 257-261:
> {code:java}
> try {
> call.waitFor(loggers.size(), loggers.size(), 0, timeoutMs,
> "format");
> } catch (InterruptedException e) {
> throw new IOException("Interrupted waiting for format() response");//no
> cause
> } catch (TimeoutException e) {
> throw new IOException("Timed out waiting for format() response");//no
> cause
> }
> {code}
> In the code snippet above, two key locations exhibit this problematic
> pattern: when catching exceptions and re-throwing a new exception instance,
> the caught original exceptions are not passed as the root cause (or "cause"
> parameter) of the new exception. Without chaining the original exception to
> the new one, the error stack trace loses critical context about the initial
> failure location, which makes tracing the source of the original exceptions
> extremely difficult and prolongs the troubleshooting process.
> Fix Suggestion:
> {code:java}
> try {
> call.waitFor(loggers.size(), loggers.size(), 0, timeoutMs,
> "format");
> } catch (InterruptedException e) {
> throw new IOException("Interrupted waiting for format() response", e);
> } catch (TimeoutException e) {
> throw new IOException("Timed out waiting for format() response", e);
> }
> {code}
> There are multiple instances of this issue in the methods of the
> {{QuorumJournalManager.java}}. (Line:257-261 275-279 682-686 699-703 716-720
> 747-753 768-772 785-791 816-822)
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
