Description
We've seen a situation where some work was failing from (recurrent) connection reset exceptions.
Irrespective of the root cause, these were surfacing not in the read operations, but when the input stream was being closed -including during a seek()
These exceptions could be caught & logged & warn, rather than trigger immediate failures. It shouldn't matter to the next GET whether the last stream closed prematurely, as long as the new one works
Attachments
Issue Links
- Is contained by
-
HADOOP-11730 Regression: s3n read failure recovery broken
- Closed
- is related to
-
HADOOP-11874 s3a can throw spurious IOEs on close()
- Resolved
-
HADOOP-11570 S3AInputStream.close() downloads the remaining bytes of the object from S3
- Closed
- relates to
-
HADOOP-11730 Regression: s3n read failure recovery broken
- Closed