Croway opened a new pull request, #29336: URL: https://github.com/apache/camel/pull/29336
## What was wrong [CAMEL-26658](https://issues.apache.org/jira/browse/CAMEL-26658): when `camel-amqp` creates the connection factory itself (`brokerUrl`, `host`/`port`/`username`/`password`/`useSsl`, the `AMQPComponent.amqpComponent(...)` factory methods, or the deprecated `AMQPConnectionDetails`), it is a plain qpid-jms `JmsConnectionFactory`. Spring `JmsTemplate` opens and closes a connection per call when the factory does not cache, so every message sent outside a consumer thread did TCP + (TLS) + SASL + AMQP open/begin/attach. With an embedded Artemis on loopback: 10 sends opened 10 broker connections. ## What changed - `AMQPComponent` keeps a Spring `CachingConnectionFactory` on the factory it created (with the credentials of the component, as `JmsComponent#createEndpoint` wraps them), when the new `cacheConnection` option is on (default `true`). It closes the shared connection when the component stops. - `AMQPConfiguration#createCamelJmsTemplate` gives the endpoints that use that factory a template that opens its connections from the cache. The template keeps the endpoint's own connection factory: Spring looks up the session of a transaction, or the listener session of the consumer running the route, by that factory instance, so a send in a transacted route still takes part in the transaction. - Setting the caching factory as `templateConnectionFactory` instead (as first proposed in the JIRA) breaks this: in `from("amqp:queue:in?transacted=true").to("amqp:queue:out")` with a forced failure on the first delivery, `out` got 2 messages instead of 1 (the first send escaped the rollback). The new test covers it. - The cache does not keep consumers (a polling consumer such as `pollEnrich` would otherwise stay attached and hold prefetched messages) nor producers (so a producer link that the broker closed is not reused). - Untouched: the listener containers and reply managers (plain factory, as before), a `connectionFactory` set by the user on the component or on an endpoint, an endpoint with its own `username`/`password`, and `cacheConnection=false`. No new dependency (`spring-jms` is already there through `camel-jms`). ## Tests - New `AMQPCachedConnectionTest` (embedded Artemis, counts broker connections): brokerUrl, host/port + credentials and the factory method send 10 messages over 1 connection; the shared connection is closed on stop; `cacheConnection=false`, a user factory on the component or endpoint, and endpoint credentials still open 10; sending recovers after a broker restart; a polling consumer closes its consumer; a send from a transacted consumer is rolled back with it. - `AMQPAuthRouteTest`: new test with `brokerUrl` + username/password against a broker with authentication (the shared connection logs in). - On `main`, 4 of the new tests fail (`expected: <1> but was: <10>` for brokerUrl, host/port and factory method; `the shared connection stays open ... expected: <1> but was: <0>`); with the fix all pass. `camel-amqp` suite: 37 tests, 0 failures. - Earlier reproducer, 200 sends after warm-up on loopback: 0 new connections and a median of about 0.3-1 ms per send, against 200 connections and about 5-7 ms with `cacheConnection=false`. ## Docs and upgrade guide - `amqp-component.adoc`: the properties example uses `camel.component.amqp.broker-url` instead of binding a plain `JmsConnectionFactory`, and a new "Connections of the producers" section explains the shared connection, how to turn it off, and to pool a user-supplied factory. - `camel-4x-upgrade-guide-4_24.adoc`: new entry (changed default, `cacheConnection=false` to get the old behaviour, all producer messages now go to one broker behind a load balancer). - Regenerated: component JSON and configurer, catalog copies, `AmqpComponentBuilderFactory`. ## Backport Not proposed for `camel-4.18.x` / `camel-4.22.x`: it changes a default (one long-lived connection instead of one per message) and the issue comes from a code survey, not a user report. _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]
