allthingssecurity opened a new pull request, #28205: URL: https://github.com/apache/camel/pull/28205
# Description [CAMEL-25816](https://issues.apache.org/jira/browse/CAMEL-25816) With `transacted=true` the Hazelcast SEDA consumer begins a Hazelcast transaction on its polling thread, polls the message inside it and commits or rolls back in the `done` callback of the asynchronous routing engine. A Hazelcast transaction can only be ended by the thread that began it (`Transaction cannot span multiple threads!`). When the route continues on another thread, for example with an asynchronous producer such as camel-kafka, or with `threads()`, the callback runs on that thread and the commit or rollback fails. The reactive executor logs it as a WARN and ignores it. The message stays reserved by a transaction that never ends: - a failed message is not rolled back, so it is not taken again; - the next poll fails with `Nested transactions are not allowed!` and waits `onErrorDelay`; - when the application leaves the Hazelcast cluster (restart, redeploy), the other members roll back its open transactions and every message it processed is put back into the queue and consumed again. Changes (`HazelcastSedaConsumer`): - With `transacted=true` the consumer thread processes the exchange synchronously (it waits for the exchange, also when the route continued on another thread) and commits or rolls back the transaction itself. The commit and rollback logic moved unchanged into `onExchangeDone`. - Without `transacted` nothing changes: the exchange is still processed asynchronously. What users can notice: a transacted consumer thread takes the next message only when the previous exchange is complete (`concurrentConsumers` gives more threads). Option description and an upgrade note in the 4.24 guide say so. Not changed: the consumer creates its exchanges with auto release, so with the pooled exchange factory the exchange is reset when its unit of work is done, before the outcome is read. That was already the case in the `done` callback on main and is the same here; it could be a follow-up (create the exchange without auto release and release it after the commit or rollback, as camel-jpa and camel-sql do). Tests: - New `HazelcastSedaTransactedAsyncRouteTest` (2 tests, two embedded Hazelcast members, a route with `threads(1)`). Without the change both fail: after the application's member leaves, the processed messages are back in the queue (`expected: <0> but was: <3>`), and a failed message is never taken again (`Expected: <1> but was: <0>`). With the change both pass (3 runs). - With the change the camel-hazelcast unit tests run 244 tests with 0 failures and 1 error, `HazelcastUserConfigSerializationFilterWarningTest.warnsForUserClientConfigWithoutFilter` (a Hazelcast client could not connect to the test member in my environment; it fails the same way without the change). How it was found: reading the transacted consumer for transaction state that crosses threads, then a probe with an embedded member, then the test above. Not run against a separate Hazelcast cluster. # 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-25816](https://issues.apache.org/jira/browse/CAMEL-25816). # 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-hazelcast, which regenerated its metadata; the catalog copy and the endpoint DSL javadoc of the changed option description were updated to match. 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]
