During lifecycle of an application, the connection pool is never getting released properly thus leading to exhaustion based on messages sent. Actually, the proper way of handling the connections with RabbitMQ is with having singe long-lived one-sided connection and bunch of (potentially) short-lived channels. Multiplexing is handled by AMQP itself, so it is thread-safe from C# perspective.
Basically, we only need 2 connections per client (incoming + outgoing) and bunch of channels.
Since the connections are "singleton", they must be as robust as possible.
The channels are still supposed to be robust, too, at least for consumers.
NTH feature: message pooling for publishers on channel/connection outage?
During lifecycle of an application, the connection pool is never getting released properly thus leading to exhaustion based on messages sent. Actually, the proper way of handling the connections with RabbitMQ is with having singe long-lived one-sided connection and bunch of (potentially) short-lived channels. Multiplexing is handled by AMQP itself, so it is thread-safe from C# perspective.
Basically, we only need 2 connections per client (incoming + outgoing) and bunch of channels.
Since the connections are "singleton", they must be as robust as possible.
The channels are still supposed to be robust, too, at least for consumers.
NTH feature: message pooling for publishers on channel/connection outage?