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)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to