AWS: handle premature connection close

[kinolaev]

During vectorized Parquet reads, S3InputStream opens an unbounded HTTP range request (bytes=pos-) and reads one row group eagerly into memory. While Spark processes that in-memory row group (which can take several minutes for large batches), the client stops reading from S3. The TCP receive buffer fills up, and S3 eventually tears down the stalled connection.

When the next row group read begins, the connection is already dead and Apache HTTP client throws ConnectionClosedException: Premature end of Content-Length delimited message body (expected: x; received: y) (when using apache http client). This only affects files with multiple row groups (typically >128 MB).

The existing retry policy handles SSLException, SocketTimeoutException, and SocketException, but not this case. This PR extends the retry predicate to reopen the stream at the saved position when this specific exception is encountered, while leaving all other ConnectionClosedException variants (e.g. from abort()) unaffected.

Fixes #9674 and #9679.

[singhpk234]

Thanks for reporting this @kinolaev !
I think this stems from the fact that row groups are read sequentially, i had a pr a while back to prefetch the row groups and this would have potentially saved us in this scenario.
PR : https://github.com/apache/iceberg/pull/7279/changes

resuming the connection from last its closed, seems like a way continue the processing,

do you know the case like your, reads ever success ? because if a fresh connection is established and we reprocess this task again from the begining we will still get into same situation ?

[singhpk234]

is there a better way to identify this rather than inspecting on exception message (it looks to fragile to me)