[smallrye-rabbitmq] Proposal/Question: Allow Multiple Channels to Share a Single RabbitMQ Connection

[CassioGangrel]

Summary

Today each mp.messaging channel that uses the smallrye-rabbitmq connector opens its own AMQP connection. In practice this means one emitting channel plus one consuming channel already establish two independent TCP connections, even if they target the same broker/exchange pair. The RabbitMQ documentation recommends reusing a single connection and opening multiple AMQP channels on top of it, so the current behaviour makes it easy to exhaust broker connection quotas in larger deployments.

Current Behaviour

• IncomingRabbitMQChannel creates a fresh RabbitMQClient per channel and memoizes its connection.
• OutgoingRabbitMQChannel follows the same pattern for producers.

Because the connector instantiates a dedicated client per channel, there is no supported way to share a single TCP connection across multiple channels.

Why This Is Problematic

• Hosted RabbitMQ clusters typically enforce connection quotas; with the current design, the number of connections grows linearly with the number of channels, making it easy to hit those limits.
• RabbitMQ best practices suggest opening one connection per app instance and multiplexing via channels instead of creating many short-lived connections.
• Users migrating from “bare” clients (e.g. Vert.x, Spring AMQP) are surprised that SmallRye cannot follow the same pattern.

Questions for Maintainers

1. Was there a historical reason to tie one RabbitMQClient (connection) to each messaging channel? E.g. compatibility, back-pressure, or resilience constraints?
2. Would the project consider a feature enhancement that allows multiple channels to share a single connection (for example by introducing a connection pool keyed by host/virtual-host + credentials)?
3. If the concern is isolation/failure propagation, could the connector offer a toggle so users can opt into shared connections while keeping the current default?

Desired Outcome

• Clarify the design rationale so we can document it internally.
• If there is no blocker, collaborate on an enhancement (or contribute one) that lets applications reuse existing connections, reducing broker load.

Note: If I misunderstood and am using the tool incorrectly, please explain to me the best way to use it.

[ozangunalp]

Thank you for the detailed issue description.
I think it makes sense to manage clients globally if the client configuration is the same, of course.

It might seem a bit complex because of the code organisation, but would you want to give it a try?

[CassioGangrel]

Yes, I’d like to give it a try. I’ll start working on it during my next Sunday break