[
https://issues.apache.org/jira/browse/CAMEL-24484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-24484:
--------------------------------
Fix Version/s: (was: 4.18.5)
> camel-file: readLockRemoveOnCommit=false is not respected when
> idempotent-changed/-rename/idempotent read lock fails to acquire an existing
> entry
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24484
> URL: https://issues.apache.org/jira/browse/CAMEL-24484
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 4.18.3, 4.22.0
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Major
> Fix For: 4.22.1, 4.23.0
>
>
> Reported on the dev/users mailing list by Sam Jebaraj.
> When using readLock=idempotent-changed (or idempotent / idempotent-rename)
> with readLockRemoveOnCommit=false, a previously committed idempotent
> repository entry is unexpectedly removed the next time a file with the same
> idempotent key is polled, even though the entry should be retained.
> Root cause: two independent issues in camel-file:
> 1)
> FileIdempotentChangedRepositoryReadLockStrategy.releaseExclusiveReadLockOnAbort()
> (and the same pattern in FileIdempotentRepositoryReadLockStrategy /
> FileIdempotentRenameRepositoryReadLockStrategy) unconditionally calls
> idempotentRepository.remove(key) whenever the read lock could not be
> acquired. This includes the case where acquireExclusiveReadLock() failed
> because idempotentRepository.add(key) returned false (i.e. the key already
> existed from a prior, already-committed run) - so this consumer never owned
> the entry, yet it removes it anyway, ignoring
> readLockRemoveOnCommit/readLockRemoveOnRollback entirely.
> 2) GenericFileConsumer's "notStarted" cleanup added by CAMEL-21947 (commit
> 71090b4b0b6) removes from endpoint.getIdempotentRepository() whenever
> endpoint.isIdempotentEager() (defaults to true) and
> endpoint.getIdempotentRepository() != null, without checking
> endpoint.isIdempotent(). For readLock=idempotent-changed setups the
> idempotent repository is populated by the read-lock strategy, not by the
> polling-time eager dedup path that CAMEL-21947 intended to guard, so this
> cleanup incorrectly removes entries it never added.
> Both bugs share the same flawed assumption: "file did not start processing"
> implies "we must have added this idempotent entry ourselves, so it is safe to
> remove" - which is false whenever the entry pre-existed.
> Fix: only remove an idempotent-repository entry when the current attempt
> actually owns it (i.e. it was added by this attempt), never when acquisition
> failed because the entry already existed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
