gnodet-bot commented on code in PR #27132:
URL: https://github.com/apache/camel/pull/27132#discussion_r4145852211
##########
components/camel-azure/camel-azure-storage-blob/src/main/java/org/apache/camel/component/azure/storage/blob/BlobBlock.java:
##########
@@ -38,11 +39,13 @@ public static BlobBlock createBlobBlock(final InputStream
inputStream) throws IO
}
public static BlobBlock createBlobBlock(final String blockId, final
InputStream inputStream) throws IOException {
- InputStream is = inputStream;
- if (!is.markSupported()) {
- is = new BufferedInputStream(is);
+ long length = PayloadHelper.getLength(inputStream);
+ if (length < 0) {
+ // the block must be read to determine its length
+ byte[] data = inputStream.readAllBytes();
+ return createBlobBlock(blockId, data.length, new
ByteArrayInputStream(data));
Review Comment:
💡 **Observation:** When `PayloadHelper.getLength()` returns -1
(unknown-length stream), this falls back to `readAllBytes()` which loads the
entire block into memory. The parallel `BlobStreamAndLength` path uses
`PayloadHelper.cacheStream(exchange, is)` which can spool to disk for large
payloads.
This path lacks an `Exchange` context, so `OutputStreamBuilder`-based
caching isn't available — the trade-off is understandable. Azure block uploads
have a max block size (typically 100 MB staging blocks), so the memory impact
is bounded. Just flagging the asymmetry for awareness.
--
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]
