allthingssecurity opened a new pull request, #28378: URL: https://github.com/apache/camel/pull/28378
# Description [CAMEL-25855](https://issues.apache.org/jira/browse/CAMEL-25855) For an InOut exchange the quickfix producer registers a correlation rule in the `MessageCorrelator` of the engine before it sends the FIX message. The rule was removed only when a matching reply arrived. A request that timed out without a matching reply (for example a Reject or BusinessMessageReject that the criteria do not match), or whose send failed (`Session.send` returned false or threw), left its rule and its exchange in the engine's list for good; every FIX message of the engine was then evaluated against all of them. Changes: - `MessageCorrelator.getReply`: the returned `Callable` removes its rule in a finally block (reply, timeout or interrupt). - New `MessageCorrelator.cancelReply(Exchange)`, used by `QuickfixjProducer` when the send fails (`Session.send` returned false or threw). The exchange then fails with `CannotSendException`, so nobody waits for a reply. A reply can still come: QuickFIX/J 3.0.2 stores an application message (`Session.sendRaw` persists it) before it finds the session not logged on, so a ResendRequest after the next logon can send it. That also means a redelivered send can reach the counterparty twice, as before this change. The rule is still registered before the send, so a fast reply is not missed. - Package-private `MessageCorrelator.pendingReplies()` (for tests), so the test does not read the rule list by reflection. No option changed, so no upgrade guide entry. Tests: - New `QuickfixjProducerCorrelationCleanupTest` (3 tests, the mocked session of `QuickfixjProducerTest`). Without the change: `correlation rules left after 50 timed out requests ==> expected: <0> but was: <50>`, and `expected: <0> but was: <1>` after a send that returned false and after a send that threw. All pass with the change. - camel-quickfix unit tests with the change: 46 run, 0 failures. How it was found: a review of request/reply correlation in producers (where a waiting request is registered and where it is removed again), then the JUnit tests. What was not run: a test against a FIX counterparty; 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-25855](https://issues.apache.org/jira/browse/CAMEL-25855). # 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 camel-quickfix. 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]
