Claus Ibsen created CAMEL-24484:
-----------------------------------
Summary: 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
Reporter: Claus Ibsen
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)
