Ruby, Puma (threaded + forking), Bunny as shared connection

[Francesco Belladonna]

Hello everyone,
I'm entirely new to RabbitMQ (I used Amazon SQS previously) and would like some clarifications.

I read some topics in the group and these are the information I gathered:

1. Share Bunny connection per process (after forking), if I have 2 processes, I'll have 2 connections (one per process)
2. One channel per thread. So if I have 4 threads and 2 processes, I'll need to have 8 channels ? I'm not completely sure about this
3. There is no need for "connection pooling", one connection per process is enough
4. What options do I have to create a channel for each thread, since Puma doesn't expose any API for when threads are created?
5. What options do I have to ensure channels are closed when a thread dies/exits normally?
6. Are channels automatically closed if the thread where they are in use die/exits normally?

I have a main web application which is just going to publish messages to a single queue, and a completely different application which is going to digest these messages.

From my understanding, both creating a connection and creating a channel are heavy operations. I need my web requests to be extremely fast (that's the main purpose of using rabbitmq) write-wise, so I need some suggestions regarding how to keep the channel and the connection open and keep using those and close only when the application is quitting or crashing.

[Michael Klishin]

3. There may be need for it but you'll know it when you get there.

4. Thread-local variables is one option I see used often.

5. That's a good question. Obviously the variables will be GC'ed but a channel is a piece of server state as well. I'm afraid the best option in Ruby is Thread#abort_on_exception (the instance method, not the class one!)
     https://ruby-doc.org/core-2.2.0/Thread.html#method-i-abort_on_exception-3D

6. No. A connection would be released because its TCP socket would be disposed and http://www.rabbitmq.com/heartbeats.html will kick in but channel disposal is exclusively application's responsibility.

--
Bunny: http://rubybunny.info
March Hare: http://rubymarchhare.info
 
IRC: #rabbitmq on irc.freenode.net
 
Post to the group: ruby...@googlegroups.com | unsubscribe: ruby-amqp+unsubscribe@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "Ruby RabbitMQ libraries" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ruby-amqp+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

MK

Staff Software Engineer, Pivotal/RabbitMQ

[ben rooney]

HI Francesco,

Based on the feedback below from Michael, did you come up with a strategy? We are looking to implement this as well but we're struggling with ensuring the channels are closed, and ultimately that the connection is closed if the server is shutdown / restarted. Have some thoughts about the restarts but not shutdown. There doesn't seem to be anywhere good to hook into

thanks in advance