[
https://issues.apache.org/jira/browse/CAMEL-24096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Federico Mariani updated CAMEL-24096:
-------------------------------------
Attachment: FtpChangedReadLockTimeoutZeroTest.java
> 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
> Priority: Major
> Labels: code-review
> 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)
