Federico Mariani created CAMEL-24122:
----------------------------------------
Summary: camel-smb: readLockTimeout=0 (documented "0 or lower =
forever") makes readLock=changed skip every file forever
Key: CAMEL-24122
URL: https://issues.apache.org/jira/browse/CAMEL-24122
Project: Camel
Issue Type: Bug
Components: camel-smb
Affects Versions: 4.21.0
Reporter: Federico Mariani
Attachments: SmbChangedReadLockTimeoutZeroIssueIT.java
h3. Problem
{{readLockTimeout}} is documented on {{GenericFileEndpoint}} as "Use a value of
0 or lower to indicate forever".
{{SmbChangedExclusiveReadLockStrategy.acquireExclusiveReadLock}}
(SmbChangedExclusiveReadLockStrategy.java:59-74) feeds the timeout straight
into a task budget:
{code:java}
BlockingTask task = Tasks.foregroundTask()
.withBudget(Budgets.iterationTimeBudget()
.withMaxDuration(Duration.ofMillis(timeout)) // 0 == already
expired
.withInterval(Duration.ofMillis(checkInterval))
.build())
{code}
{{TimeBoundedBudget}} treats only the sentinel {{-1}} as unlimited
({{UNLIMITED_DURATION}}); with {{maxDuration=0}} (or any other negative value)
{{canContinue()}} is immediately false, {{ForegroundTask.run}} never executes a
single iteration, and {{acquireExclusiveReadLock}} returns false - logging
{{Cannot acquire read lock within 0 millis. Will skip the file}} for *every
file on every poll*. The consumer never consumes anything.
h3. Failure scenario
{{smb://...?readLock=changed&readLockTimeout=0}} - configured per the
documentation to wait forever - consumes zero files, forever, with only a WARN
per poll.
h3. Related
This is the same defect as CAMEL-24096 in camel-ftp
({{FtpChangedExclusiveReadLockStrategy}} has the identical Tasks/Budgets
pattern); camel-smb copied the pattern. A shared fix (map {{timeout <= 0}} to
{{UNLIMITED_DURATION}} before building the budget, or fix the budget builder
itself) would close both.
h3. Reproducer
Attached failing IT (place in
{{components/camel-smb/src/test/java/org/apache/camel/component/smb/}}): a
static file with
{{readLock=changed&readLockCheckInterval=100&readLockTimeout=0}} is never
delivered to the mock within 20s (a working "forever" lock acquires after ~2
checks, i.e. ~200ms).
----
_This issue was researched and filed by Claude Code on behalf of [~fmariani]
(GitHub: Croway), as part of a deep code review of camel-smb. A failing JUnit
reproducer is attached; it fails deterministically on current main
(4.22.0-SNAPSHOT) against the Samba testcontainer used by the existing
camel-smb ITs._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
