[
https://issues.apache.org/jira/browse/HDFS-17796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18076492#comment-18076492
]
ASF GitHub Bot commented on HDFS-17796:
---------------------------------------
1fanwang opened a new pull request, #8460:
URL: https://github.com/apache/hadoop/pull/8460
### Description of PR
JIRA: [HDFS-17796](https://issues.apache.org/jira/browse/HDFS-17796)
WebHDFS write failures caused by storage-capacity limits today surface as a
generic HTTP 403 (or, when the channel times out before the handler runs, 500).
Clients have no way to distinguish "out of space" from permission denial or
transient server failure.
Both ExceptionHandlers — NameNode-side
(`o.a.h.hdfs.web.resources.ExceptionHandler`) and DataNode-side
(`o.a.h.hdfs.server.datanode.web.webhdfs.ExceptionHandler`) — currently fall
through to the generic `IOException -> FORBIDDEN (403)` mapping for the
storage-capacity exception family.
### Fix
Add a typed mapping ahead of the generic `IOException` branch:
- `ClusterStorageCapacityExceededException` (and subclasses, including
`DSQuotaExceededException` / `NSQuotaExceededException`)
- `DiskChecker.DiskOutOfSpaceException`
both map to **HTTP 507 Insufficient Storage** (RFC 4918).
JAX-RS 2.1's `Response.Status` enum doesn't include 507, so the NN-side
handler defines a small `Response.StatusType` constant. The DN-side handler
uses Netty's built-in `HttpResponseStatus.INSUFFICIENT_STORAGE`.
### How was this patch tested?
Two new unit tests, one per handler package:
- `org.apache.hadoop.hdfs.web.resources.TestExceptionHandler` — 6 tests
- `org.apache.hadoop.hdfs.server.datanode.web.webhdfs.TestExceptionHandler`
— 6 tests
```
[INFO] Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
```
Each suite covers `DSQuotaExceededException`, `NSQuotaExceededException`,
`DiskOutOfSpaceException`, plus regression checks for the existing mappings
(`IOException -> 403`, `FileNotFound -> 404`, `IllegalArgument -> 400`).
### Out of scope
HDFS-17796 also asks for cleanup of incomplete files left behind by failed
writes. That part is intentionally not included here — it requires plumbing the
file path through `HdfsWriter` so the handler can attempt a best-effort delete
on failure, and is best handled in a follow-up PR so the status-code fix can
land independently. Happy to follow up.
### For code changes:
- [x] Does the title of this PR start with the corresponding JIRA issue id?
- [x] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)? (no new
dependencies)
> File write via WebHDFS when required space not available doesn't give
> appropriate error on failing
> --------------------------------------------------------------------------------------------------
>
> Key: HDFS-17796
> URL: https://issues.apache.org/jira/browse/HDFS-17796
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: webhdfs
> Reporter: Atin Arora
> Priority: Major
>
> When initiating a write operation through WebHDFS to upload a large file (~10
> GB), if the available HDFS storage is less than the size of the file, WebHDFS
> responds with an HTTP 500 Internal Server Error. This error response is
> generic and does not clearly indicate the actual cause — insufficient storage
> space. Additionally, the partial or incomplete file that is created during
> the upload process is not cleaned up from HDFS, which may lead to further
> storage issues or confusion for users and automated processes.
> +*STEPS TO REPRODUCE:*+
> # Almost fill the available storage in HDFS, leaving ~5gb of space
> # Initiate a webHDFS call to upload a large file (~10gb)
> # Wait for the operation to timeout
> +*CURRENT BEHAVIOUR:*+
> Currently the webHDFS call times out with a 500 response code
> +*EXPECTED BEHAVIOUR:*+
> * The server should return a meaningful error (e.g., *HTTP 507 Insufficient
> Storage* or a descriptive 400-level error) indicating that there is not
> enough space to complete the operation.
> * There shouldn't be any incomplete files on the node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
