Croway opened a new pull request, #29344: URL: https://github.com/apache/camel/pull/29344
## What was wrong [CAMEL-26693](https://issues.apache.org/jira/browse/CAMEL-26693): with only `brokerURL` set, each `activemq` / `activemq6` endpoint creates its own connection factory (by default its own pooled-jms pool), so a message sent from a transacted route is not part of the transaction of the consumer. While measuring the options, a lifecycle bug showed up: the component registers each of those factories, and `ActiveMQComponent#doStop` stopped them and forgot them, while the endpoints kept them. A pooled-jms pool gives no connection once stopped, so after a component stop and start every send failed with `ConnectionFactory returned null from createConnection()`. The single connection factories (`useSingleConnection=true`) were reset and forgotten too, so the connection they opened after a restart was never closed. ## What changed - `ActiveMQComponent#doStop` (camel-activemq and camel-activemq6): closes the connections of the registered factories and keeps them usable (`JmsPoolConnectionFactory#clear`, `SingleConnectionFactory#resetConnection`). The endpoints open new connections when they are used again. - `ActiveMQComponent#doShutdown`: stops the factories (`JmsPoolConnectionFactory#stop`, `SingleConnectionFactory#destroy`) and forgets them. - Docs (both components, catalog copies refreshed), new section "Connection factory and transactions": - with only `brokerURL`, a message sent from a transacted route is not part of the transaction of the consumer; - to get that, set one `connectionFactory` on the component, and any `transactionManager` on that same factory; - endpoints with their own `clientId` need their own factory when the pool is shared, and `useSingleConnection=true` cannot be combined with a `clientId`. ## Why the factory is not shared by default Measured with an embedded ActiveMQ Classic 6.3.2 broker and pooled-jms 3.2.5: - One shared pool fixes the transaction, but endpoints with different `clientId` values cannot share it: the second one never subscribes and retries forever with "Setting clientID on a used Connection is not allowed". - One pool for all endpoints puts a component-wide limit of 500 sessions on it, and `blockIfSessionPoolIsFull` waits forever: with 4 endpoints and 130 consumers each, a send was still blocked after 10 seconds. With the pool per endpoint it went through. - The broker connections drop from one or more per endpoint to one. - A transaction manager on its own factory does not help: the sent message was still not rolled back. So the default is unchanged, and the docs show how to share one factory. ## Tests - camel-activemq6, embedded broker: `ActiveMQComponentRestartTest`: component stop/start (pooled and single connection, plus the connections closed at the next stop), route stop/start, CamelContext stop/start, and shutdown (no broker connection left, the pool is stopped). - camel-activemq (no broker; its ITs use a container): `ActiveMQComponentRestartTest`: the pool of an endpoint is usable after a component stop/start, and stopped when the CamelContext stops. - On `main`: 2 of 5 activemq6 tests fail (`ConnectionFactory returned null from createConnection()` after the restart; the single connection still open after the second stop), and 1 of 2 activemq tests (the stopped pool gives no connection). With the fix all pass. - Test scope only: `activemq-broker` (same version as the client) for an embedded broker in camel-activemq6, which had no unit tests, and `pooled-jms` in both modules, as the default `usePooledConnection=true` loads it and the modules do not depend on it. - Module unit tests pass. The ITs of both modules need a container and were not run. ## Upgrade guide No entry: the endpoints now work after a restart, and the connections are still closed when the component stops. _Claude Code on behalf of Federico Mariani_ -- 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]
