Federico Mariani created CAMEL-24096:
----------------------------------------
Summary: camel-ftp: readLockTimeout=0 (documented as forever)
makes readLock=changed never acquire the lock on FTP/FTPS/SFTP - regression
from CAMEL-17121 Tasks conversion
Key: CAMEL-24096
URL: https://issues.apache.org/jira/browse/CAMEL-24096
Project: Camel
Issue Type: Bug
Components: camel-ftp
Affects Versions: 4.21.0
Reporter: Federico Mariani
Attachments: FtpChangedReadLockTimeoutZeroTest.java
h3. Problem
{{GenericFileEndpoint.readLockTimeout}} docs: "Use a value of 0 or lower to
indicate forever".
{{FtpChangedExclusiveReadLockStrategy.acquireExclusiveReadLock}}
(FtpChangedExclusiveReadLockStrategy.java:57-67) builds:
{code:java}
BlockingTask task = Tasks.foregroundTask()
.withBudget(Budgets.iterationTimeBudget()
.withMaxDuration(Duration.ofMillis(timeout)) // timeout = 0
...
{code}
In {{TimeBoundedBudget}} only {{-1}} ({{UNLIMITED_DURATION}}) means unlimited -
{{0}} fails {{elapsed() >= maxDuration}} immediately, so {{task.run(...)}}
returns false before the first iteration and {{tryAcquireExclusiveReadLock}} is
never invoked. Every file is skipped every poll with "Cannot acquire read lock
within 0 millis. Will skip the file" - the consumer silently consumes nothing,
forever. {{SftpChangedExclusiveReadLockStrategy}} has the identical regression.
({{-1}} coincidentally still works; {{0}} and other negative values do not.)
h3. Failure scenario
{{ftp://...?readLock=changed&readLockTimeout=0}} (a documented configuration
for slow producers writing large files): zero files are ever consumed. Same for
sftp.
h3. History
Before CAMEL-17121 (ae7928cab7fa, Camel 3.14) the loop guarded the timeout with
{{if (timeout > 0) { ... }}}, so 0 genuinely meant wait-forever. The
Tasks/budget conversion dropped that branch. Other Tasks conversions from the
same effort may deserve the same audit.
h3. Suggested fix
{{timeout <= 0 ? withUnlimitedDuration() :
withMaxDuration(Duration.ofMillis(timeout))}} in both strategies.
h3. Reproducer
Attached failing JUnit test (place in
{{components/camel-ftp/src/test/java/org/apache/camel/component/file/remote/}}).
No server needed - stubs the remote operations with a stable file listing and
asserts that {{acquireExclusiveReadLock}} with {{timeout=0}} acquires the lock;
on current main it returns false immediately.
----
_This issue was researched and filed by Claude Code on behalf of [~croway]
(GitHub: Croway), as part of a deep code review of camel-file and camel-ftp. A
failing JUnit reproducer is attached; it fails deterministically on current
main (4.22.0-SNAPSHOT)._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
