Running into a timeout when publishing messages from Ruby on Rails

[GuilhermeTrivilin]

I'm facing a timeout issue when attempting to publish messages to a RabbitMQ queue in my Ruby on Rails application. I'm using the Bunny gem for connection and message publishing. The connection to RabbitMQ is successfully established, but when I try to publish a message, it times out. Interestingly, running the same publishing code directly through Rails Console works perfectly.

Here’s the setup for my connection initializer:

# config/initializers/rabbitmq.rb
require 'bunny'

unless Rails.env.test?
  RABBITMQ_CONN = Bunny.new(
    host: ENV['RABBITMQ_HOST'] || 'localhost',
    port: ENV['RABBITMQ_PORT'] || 5672,
    username: ENV['RABBITMQ_USER'] || 'guest',
    password: ENV['RABBITMQ_PASSWORD'] || 'guest'
  )

  RABBITMQ_CONN.start
end

And here is the service responsible for publishing messages:

# app/service/rabbitmq/point_calculations_publisher.rb
class Rabbitmq::PointCalculationsPublisher
  def self.publish(message)
    channel = RABBITMQ_CONN.create_channel
    queue = channel.queue('point_calculations', durable: true)
    queue.publish(message.to_json, persistent: true)
  ensure
    channel&.close
  end
end

Environment Details: Ruby version: 2.5.6 Rails version: 5.2 Bunny gem version: 2.19 Troubleshooting Steps Taken: Verified that the connection works, as I can successfully connect. Tested publishing through Rails Console, which works as expected without timeouts. Additional Context: The timeout occurs only when publishing within the Rails application itself. I suspect it might be related to how the Bunny connection is being handled in production vs. Rails Console.

Any insights or solutions from those who have encountered similar issues would be highly appreciated!

[michaelklishin]

@GuilhermeTrivilin filing issues with questions in repositories that have Discussions enabled in 2024 is just rude.

Start with inspecting server logs.

Your code has all three most common beginner mistakes:

• You open a new channel per message which is an exact opposite of how channels are supposed to be used
• You re-declare your topology, namely the target queue, for every message published. Publishers are not supposed to know about individual queues most of the time. Instead, on application boot you can do a passive declare (ch.queue("queue.name", passive: true)) on a one-off channel, and in case an exception is thrown (the queue does not exist), declare it once and not for every message published
• Your code assumes that when queue.publish (Bunny::Channel#publish that uses the default exchange) returns, the message has reached the broker. That is not at all the case, you must use publisher confirms

I'm not sure that

channel&.close

is syntactically valid Ruby.

In general, this kind of code can quickly beyond the default maximum channel limit, after which the connection will be closed
with an error, which will be very visible in broker logs.

[michaelklishin]

In other words, besides inspecting/tailing server logs and learning about how channels are meant to be used and publisher confirms, one specific change would be to

1. Use an initializer to open a connection and a channel
2. The same or another initializer that runs after the first and declares the topology the publisher must have in place (publishers declare queues only in the simplest cases and when they do not change often)
3. When it's time to publish, use Bunny::Channel#open? to see if the channel needs reopening and if it does, reopen it and re-enable publisher confirms
4. Publish and handle publisher confirms, which with Bunny means option 2 and 3 because Bunny does not support streaming confirms

Then tail logs, watch for inbound connections and take a traffic capture, in particular if the node is running locally.

And then there are several troubleshooting guides for

• Network connectivity
• TLS
• Authentication
• Authorization