davsclaus opened a new pull request, #24747:
URL: https://github.com/apache/camel/pull/24747
## Summary
Fix two bugs in `FileLockExclusiveReadLockStrategy`:
- **IOException fall-through returns `true` with no lock held**: When
`IOException` occurs during lock acquisition (file deleted between poll and
lock, permission error, Windows AV lock) with `timeout > 0`,
`handleIOException` returned `false`, causing the catch block to NOT return
`false`. Control fell through: the `finally` block deleted the `.camelLock`
marker file (via `releaseExclusiveReadLockOnAbort`), then the method returned
`true` with `lock = null` — the consumer would process the file with no OS lock
and no marker protection, enabling duplicate consumption by competing
consumers. Now always returns `false` on `IOException`.
- **Wrong property key in `doReleaseExclusiveReadLock`**: Used
`FILE_LOCK_EXCLUSIVE_LOCK` instead of `FILE_LOCK_RANDOM_ACCESS_FILE` to
retrieve the `RandomAccessFile`, so `rac` was always `null`. No fd leak today
only because closing the `FileLock`'s channel closes the shared fd, but the
code was silently wrong.
The IOException fall-through dates to CAMEL-1195 (2008, deliberate "process
anyway on Windows-AV" degradation). CAMEL-5324 (2012) later layered marker
files into this strategy, and CAMEL-7988 (2014) added the `finally` cleanup —
the combination silently dropped the cross-JVM protection that CAMEL-5324 added.
## Test plan
- [x] New `FileLockExclusiveReadLockStrategyTest` — makes file read-only so
`RandomAccessFile("rw")` throws, asserts `acquireExclusiveReadLock` returns
`false` and marker file is cleaned up
_Claude Code on behalf of davsclaus_
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
