allthingssecurity opened a new pull request, #27110: URL: https://github.com/apache/camel/pull/27110
# Description [CAMEL-25155](https://issues.apache.org/jira/browse/CAMEL-25155) The Idempotent Consumer EIP (eager, the default) calls `repository.add(key)` without a lock and processes the message only when it returns true. So `add` has to be atomic. `SpringRedisIdempotentRepository.add` is not atomic: ```java if (!contains(key)) { // SISMEMBER return setOperations.add(repositoryName, key) != null; // SADD } ``` Two consumers can receive the same message id at the same time, on one node or on two nodes sharing the Redis set (which is the reason to use this repository). Both see the key missing and both call `SADD`. `SADD` is atomic and returns the number of members it added, 1 for the first caller and 0 for the second. But the result is compared with `null`, which is true for both, so the message is processed twice. This change: call `SADD` alone and return true only when it added the key (`added != null && added > 0`). That is one round trip instead of two. The `IdempotentRepository.add` contract ("true if this repository did not already contain the key") is unchanged. Inside a pipeline or a transaction, Spring Data Redis returns null, and `add` returns false there as before. `SpringRedisStringIdempotentRepository` uses `SET NX` and is not affected. Tests: - `SpringRedisIdempotentRepositoryTest` (mocked `SetOperations`, as in the existing tests) gets two new tests. `shouldReturnTrueWhenKeyIsAdded`: `SADD` returns 1. `shouldReturnFalseWhenKeyIsAlreadyInTheSet`: `SISMEMBER` says the key is missing, and `SADD` returns 0 because another consumer added it in between. - Without the change, `shouldReturnFalseWhenKeyIsAlreadyInTheSet` fails (`expected: <false> but was: <true>`). - With the change, all camel-spring-redis tests pass: 125 tests, 0 failures. - I also checked the change against a real Redis server (a local redis-server). I did not use the test-infra container because Docker is not available on my machine. Two repository instances with their own connection factories (two nodes) and four threads added the same 500 keys, the threads meeting at a barrier before each key. Without the change, the first key was already added twice. With the change, every key was added exactly once. That test is not part of this PR, as the module's Redis tests are manual ITs. Found with a TLA+ model of consumers calling `add` with the check and the insert as separate steps, which finds the double processing in four steps and holds with an atomic `add`. I then reproduced it with the real class and a local Redis. # 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). # 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 and tested the affected module, including the formatter and import-sort plugins. 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]
