RabbitMQ: shared connections with context safety and config mismatch guard

[CassioGangrel]

Summary

• Add shared-connection-name support to reuse a single RabbitMQ connection across channels.
• Preserve incoming event-loop context even when a shared connection is created by outgoing first.
• Add a fingerprint check so channels using the same shared-connection-name must have identical connection settings.
• Add/adjust tests for shared connections and context.

Configuration

Example:

mp.messaging.incoming.data.shared-connection-name=shared-connection
mp.messaging.outgoing.sink.shared-connection-name=shared-connection

If two channels share the same name but have different connection settings, startup fails with:
Shared connection '<name>' has mismatched configuration...

Breaking changes / Documentation

• No breaking changes (feature is opt-in).
• Suggest documenting shared-connection-name and the config mismatch guard.
• Testing ./mvnw -pl smallrye-reactive-messaging-rabbitmq -DskipITs test

Simple flowchart:

flowchart TD
  IN[Incoming channel] -->|shared-connection-name| CONN[RabbitMQConnector]
  OUT[Outgoing channel] -->|shared-connection-name| CONN

  CONN -->|getClientHolder| POOL[sharedClients by name]
  POOL -->|compute fingerprint| FP[compare or create]

  FP -->|ok| CLIENT[(RabbitMQClient shared)]
  FP -->|mismatch| ERR[fail startup]

  CLIENT --> INCTX[Incoming event-loop context]
  CLIENT --> OUTCTX[Outgoing caller context]
  CLIENT --> MET[metrics/connection name using shared label]

Loading

Fixes #3189

[ozangunalp]

Instead of this, we can use the options.toJson().encode() and create the sha of that representation.

[CassioGangrel]

Using options.toJson().encode() may introduce some risks, since it includes fields that are not relevant to the connection’s identity and may not preserve the original order. The current fingerprint normalizes the data, avoiding volatility. I may be mistaken. What do you think?

We could use .toJson() and, from it, only remove the fields and normalize the lists. That could make the code more concise.

[ozangunalp]

Won't the shared client switch context with each channel with shared connection ?

[CassioGangrel]

No. In a shared connection, the ClientHolder keeps a single connection context set once via ensureContext (compare-and-set) and it does not switch per channel. Each IncomingRabbitMQChannel creates its own context for message processing and passes it to IncomingRabbitMQMessage, so ack/nack runs on the channel context, not a per-channel connection context.