allthingssecurity opened a new pull request, #27339:
URL: https://github.com/apache/camel/pull/27339

   # Description
   
   [CAMEL-25298](https://issues.apache.org/jira/browse/CAMEL-25298)
   
   `RocketMQReplyManagerSupport.handleReplyMessage` looked up the reply handler 
of an InOut exchange with `timeoutMap.get(key)` and removed it afterwards with 
`timeoutMap.remove(key)`. Between the two:
   
   - the request timeout can expire: the timeout map's purge removes the entry 
and calls `onTimeout`, which completes the exchange with an 
`ExchangeTimedOutException`; the reply thread then still calls `onReply`, which 
writes the reply into the completed exchange and completes it again;
   - a second copy of the reply can be handled by another thread of the reply 
consumer (RocketMQ delivers at least once, and the listener is concurrent): 
both threads find the handler and both complete the exchange.
   - the reply manager stops and its timeout map drains the pending handlers 
(CAMEL-24124), calling `onTimeout` for each, while a reply thread already got 
the handler.
   
   Completing the exchange twice runs the rest of the route twice. camel-jms 
and camel-sjms call `correlation.remove(id)` once and only use the handler they 
removed.
   
   This change does the same: `handleReplyMessage` removes the handler in one 
step (`DefaultTimeoutMap.remove` and the purge take the same lock, so exactly 
one of the reply, a duplicate and the timeout gets it) and only completes the 
exchange when it removed it. `cancelMessageKey` also removes in one step 
instead of `get` and then `remove`.
   
   The defect was found with a TLA+ model of the request-reply correlation 
(send and send callback, responder, reply consumer threads, timeout eviction): 
"the exchange is completed at most once" is violated by the timeout race and by 
a duplicate reply without any timeout; with the single removal it holds for up 
to 3 copies of the reply, the timeout and a failed send.
   
   Not in this PR: the same model shows that a reply arriving before the send 
callback registered the handler is ignored (the producer registers in 
`onSuccess`, camel-jms registers before sending). That needs the producer to 
change (the same method that CAMEL-25272 just changed), and is described in the 
JIRA as a follow-up.
   
   No upgrade guide entry.
   
   Tests: new `RocketMQReplyManagerSupportTest` (no broker: the reply manager 
without its reply topic consumer, a timeout map with a clock controlled by the 
test, and a hook that runs just before the reply thread removes the handler):
   - the request times out while the reply is handled: completed once, with the 
`ExchangeTimedOutException`;
   - a duplicate of the reply is handled at the same time: completed once, with 
the reply;
   - a single reply (control).
   
   Without the main-code change:
   ```
   RocketMQReplyManagerSupportTest.testTimeoutWhileReplyIsHandled: The exchange 
should be completed once ==> expected: <1> but was: <2>
   RocketMQReplyManagerSupportTest.testDuplicateReply: The exchange should be 
completed once ==> expected: <1> but was: <2>
   ```
   With the change the 3 tests pass. The module's other tests are ITs that need 
Docker (not run). Note that the module skips its tests on aarch64 
(`skipTests.aarch64`); I ran them with `-DskipTests.aarch64=false 
-DskipTests=false`.
   
   # 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]

Reply via email to