[
https://issues.apache.org/jira/browse/CAMEL-19254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18086490#comment-18086490
]
Claus Ibsen commented on CAMEL-19254:
-------------------------------------
This is Azure SDK intentional behavior, not a Camel bug.
The Azure SDK's BlobInputStream (used by openInputStream()) reads blobs in
chunks. On the first chunk it captures the blob's ETag and sets it as an
if-match condition on subsequent chunk requests. If the blob is modified
between chunks (changing its ETag), Azure returns HTTP 412 ConditionNotMet.
This is by design in the Azure SDK — it ensures read consistency so you don't
get half of version A concatenated with half of version B, which would be data
corruption.
Workarounds:
- Use the fileDir option so the consumer downloads the blob atomically via
downloadBlobToFile instead of streaming
- Use blob snapshots — read from an immutable snapshot ID via the snapshotId
option
- Use blob versioning — read from a specific version via the versionId option
- Avoid modifying blobs while they are being consumed
The regression between 3.16.0 and 3.17.0 is likely due to an Azure SDK
dependency bump that changed default ETag-locking behavior in
StorageInputStream.
Closing as Won't Fix. Added a documentation note in PR
https://github.com/apache/camel/pull/23803
> camel-azure - Azure Blob file download conditionNotMet error
> ------------------------------------------------------------
>
> Key: CAMEL-19254
> URL: https://issues.apache.org/jira/browse/CAMEL-19254
> Project: Camel
> Issue Type: Bug
> Components: camel-azure
> Affects Versions: 3.17.0, 3.18.0, 3.19.0, 3.20.3
> Reporter: Idorasi Paul
> Priority: Minor
>
> When downloading blobs using the camel component a ConditionNotMet exception
> is thrown. The condition that is not met is the if-match condition that
> contains the etag value of the blob. When endpoint polls the file, it
> attempts to download it in chunks. During the download, if the file is
> touched, the etag changes and the download fails, after that everything goes
> to hell. This does not happens on local, I think that downloading the file is
> much, much faster and this concurrency issue does not occur, but as soon as
> you switch to a real azure environment the issue will occur every time. To
> reproduce the error follow the steps:
> # Start application in debug mode
> # Add a breakpoint on StorageInputStream at line 317
> # Skip first chunk download
> # Go to azure blob and touch the file (add new metadata)
> # Skip second chunk download
> # Exception is thrown
>
> Last version that works without this issue is 3.16.0
> [Zulip chat
> topic|https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/CamelAzureBlob.20endpoint.20prefix]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
