5
votes

Using a java client for RabbitMQ, I have created a connection pooling mechanism that has a set of rabbitmq connections established and available. Once a client leases a connection the client creates a channel. If I have to send perform tasks and send 100 messages, for each of those messages the client will lease a connection and create a channel with the API such as:

rqConnection = MyPoolManager.leaseConnection();
rqChannel = rqConnection.createChannel();

Can I have a channel pre-established within my pool as one channel per connection, or a channel can always be created prior to send a message ? My concern is that creating channels over channels might consume resources. I can have the channel co-exist with a Class that contains both the connection and the channel so it is always pre-created ahead of its usage need. If the channel creation poses no resource consumption or leakage implications, then I can proceed with my current approach.

1
After viewing this question it appears to me my question above is even more valid. Pooling on Channels appears to be valid. What is undocumented or not fully understood is how to create the appropriate ratio of Connections and Channels ( how many channels per connection ) and how to acomodate capacity based on that. Pooling on a single connection and multiple channels is likely wrong, so my question is about how to define that ratio.gextra

1 Answers

13
votes

Based on additional research and observation from other groups, here are some facts about channels:

  • it appears that there are no documents specifying how to calculate the ration of number of channels per connection, neither for the benefits of running multiple connections vs multiple channels per connection
  • running a large number connections appears to be more resource consuming than running a large number of channels. Also, connections are limited to a certain number of file descriptors, whereas Channels are not.
  • some individual tests revealed the performance benchmarking of pooling connections versus pooling channels is similar

So the best approach appears to be in favor of having one connection and pool on multiple channels, where each channel would be provided by a different thread ( to prevent concurrency issues ).