oscerd commented on PR #28952: URL: https://github.com/apache/camel/pull/28952#issuecomment-6588539064
Thanks Claus, you are right that `close()` downloads the rest of the object: the SDK stream is an `AbortableInputStream` over HttpCore's `EofSensorInputStream`, and `ContentLengthInputStream.close()` reads to the end to reuse the connection. Before switching, I checked `abort()` against a local HTTP server serving a 256 MB object (read 100 bytes, then close or abort). With the default transport of the SDK, Apache HttpClient 5 (what `OSSClient.newBuilder()`, and so `OSSUtils.createClient`, use), `abort()` calls the graceful `close()` of the `CloseableHttpResponse`, which closes and drains the entity the same way: the server sent all 256 MB for both. Only the opt-in HttpClient 4 transport aborts without reading (2.6 MB). A real abort on HttpClient 5 works by unwrapping the SDK stream (`AbortableInputStream.unwarp()`) and calling HttpCore's `EofSensorInputStream.abort()`, but that ties the component to the transport internals of the SDK. So I kept `close()`, and the consumer section of the doc now says that closing a stream that was not read to its end still downloads the rest of the object, for a route that does not read it and for a consumer that stops in the middle of a poll. I can do the HttpClient 5 abort in a follow-up if you think it is worth it; the cleaner fix would be in the SDK, whose `Abortable` could close the response with `CloseMode.IMMEDIATE`. Thanks, `autocloseBody` stays out. _Claude Code on behalf of Andrea Cosentino (oscerd)_ -- 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]
