allthingssecurity opened a new pull request, #28379: URL: https://github.com/apache/camel/pull/28379
# Description [CAMEL-25856](https://issues.apache.org/jira/browse/CAMEL-25856) `GenericFileProducer` takes a lock per target file name around the write, so that two exchanges do not write the same file at the same time (CAMEL-3584, concurrent appends). The locks were kept in an LRU cache of 100 entries. The cache keeps the 100 file names used last, not the files being written: while one exchange was still writing a file, writing 100 other file names with the same producer evicted its lock, and the next exchange for that file got a new lock and wrote at the same time. With `fileExist=Append` the two contents were mixed in the file, without any error. Changes: - `GenericFileProducer`: the locks are kept in a `ConcurrentHashMap` with a count of the exchanges that hold or wait for each lock (changed in `compute` / `computeIfPresent`). The last one removes the lock, so the map only holds the file names being written and no lock is replaced while it is in use. - The `doStart` / `doStop` overrides that started and stopped the LRU cache are removed. No option changed, so no upgrade guide entry. Tests: - New `FileProducerSameFileLockTest` in camel-file (2 tests, the producer called from two threads, no route). A first exchange appends `AAAA` and then its body stream blocks; the producer writes other files; a second exchange appends `BBBB` to the same file. The test sees the second exchange either park on a lock (`LockSupport.getBlocker` of its thread) or complete its write, so it needs no fixed wait. With 10 other files the second exchange waits on main and with the change. With 150 other files, without the change: `the two appends to same.txt are mixed ==> expected: <AAAAAAAABBBB> but was: <AAAABBBBAAAA>`; it passes with the change. - camel-file unit tests with the change: 30 run, 0 failures. - camel-core file component tests (`org.apache.camel.component.file.**`) with the change: 474 run, 0 failures, 0 errors, 12 skipped (manual tests). How it was found: a review of bounded caches (`LRUCacheFactory`) whose entries can still be in use when they are evicted, then the JUnit test. What was not run: the camel-ftp and camel-smb test suites (camel-smb uses the same producer code; the FTP/SFTP producers do not take this lock); the full root build. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it): [CAMEL-25856](https://issues.apache.org/jira/browse/CAMEL-25856). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built camel-file and ran the camel-core file tests. No option changed. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 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]
