This repository has been archived by the owner on Feb 12, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 5
Incorrect usage of RabbitMQ connections can lead to socket exhaustion #21
Comments
Crevitus
pushed a commit
that referenced
this issue
Feb 22, 2019
Attempts to cache the connection per client creation to prevent creation of clients on multiple threads creating many connections. Will remove the connection from the connections dictionary if there is no longer a reference to it. See #21
Crevitus
pushed a commit
that referenced
this issue
Feb 25, 2019
There is a limit to the number of channels that can be created per connection, this is 2047. We handle this by creating a new connection when we run out of channels and offer that to new clients. See #21
Crevitus
pushed a commit
that referenced
this issue
Feb 25, 2019
Crevitus
pushed a commit
that referenced
this issue
Feb 25, 2019
Channels and connections must be closed before being disposed. See #21
Crevitus
pushed a commit
that referenced
this issue
Mar 19, 2019
This follows the guidance in https://www.rabbitmq.com/dotnet-api-guide.html#disconnecting See #21
Crevitus
pushed a commit
that referenced
this issue
Mar 19, 2019
Crevitus
pushed a commit
that referenced
this issue
Mar 19, 2019
… RabbitMQ client. The RabbitMQQueueClient is concerned with channels rather than the connection. This complexity is therefore hidden in the connection manager to ensure that connections are reused and disposed of correctly. See #21
Crevitus
pushed a commit
that referenced
this issue
Mar 19, 2019
Crevitus
pushed a commit
that referenced
this issue
Mar 22, 2019
Crevitus
pushed a commit
that referenced
this issue
Mar 22, 2019
Crevitus
pushed a commit
that referenced
this issue
Mar 22, 2019
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Problem
Incorrect usage of RabbitMQ connections can lead to socket exhaustion.
The library doesn't treat RabbitMQ connections as singletons. Every instance of
RabbitMQQueueClient
created by an application will create a new connection to RabbitMQ.The recommended approach for RabbitMQ is to share a single connection.
Suggestion
The
RabbitMQQueueClient
instance should internally cache the connection so that it can be reused for subsequent instances. The connection could be cached by a hash of theRabbitMQQueueClientFactoryOptions
to ensure that multiple connections for different RabbitMQ hosts can be supported. Only options that relate to the connection should be used for the hash.It is recommended that a single connection but multiple channels are used, therefore each instance of
RabbitMQQueueClient
should still create it's own channel.References
https://derickbailey.com/2014/03/26/2-lessons-learned-and-3-resources-for-for-learning-rabbitmq-on-nodejs/
https://stackoverflow.com/questions/10407760/is-there-a-performance-difference-between-pooling-connections-or-channels-in-rab
http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2012-March/018683.html
The text was updated successfully, but these errors were encountered: