About this guide

This guide describes tools and strategies that help in troubleshooting and debugging applications that use AMQP in general and the Ruby amqp gem in particular.

Covered versions

This guide covers Ruby amqp gem 1.0.×.

First steps

Whenever something doesn’t work, check the following things before asking on the mailing list:

Inspecting AMQP broker log file

In this section we will cover typical problems that can be tracked down by reading the AMQP broker log. We will use RabbitMQ as an example, however, different AMQP brokers often log most of the same issues.

RabbitMQ logs abrupt TCP connection failures, timeouts, protocol version mismatches and so on. If you are running RabbitMQ, log locations for various operating systems and distributions are documented in the RabbitMQ installation guide

On Mac OS X, RabbitMQ installed via Homebrew logs to $HOMEBREW_HOME/var/log/rabbitmq/rabbit@$HOSTNAME.log. For example, if you have Homebrew installed at /usr/local and your hostname is giove, the log will be at /usr/local/var/log/rabbitmq/rabbit@giove.log.

Here is what authentication failure looks like in a RabbitMQ log:

=ERROR REPORT==== 17-May-2011::17:37:58 === exception on TCP connection <0.4770.0> from {channel0_error,starting, {amqp_error,access_refused, "AMQPLAIN login refused: user 'pipeline_agent' - invalid credentials", 'connection.start_ok'}}

This means that the connection attempt with username pipeline_agent failed because the credentials were invalid. If you are seeing this message, make sure username, password and vhost are correct.

The following entry:

=ERROR REPORT==== 17-May-2011::17:26:28 === exception on TCP connection <0.4201.62> from {bad_header,<<65,77,81,80,0,0,9,1>>}

means that the client supports AMQP 0.9.1 but the broker doesn’t (RabbitMQ versions pre-2.0 only support AMQP 0.8, for example). If you are using amqp gem 0.8 or later and seeing this entry in your broker log, you are connecting to an AMQP broker that is too old to support this amqp gem version. In the case of RabbitMQ, make sure that you run version 2.0 or later.


Handling channel-level exceptions

A broad range of problems result in AMQP channel exceptions: an indication by the broker that there was an issue that the application needs to be aware of. Channel-level exceptions are typically not fatal and can be recovered from. Some examples are:

and so on. When troubleshooting AMQP applications, it is recommended that you detect and handle channel-level exceptions on all of the channels that your application may use. For that, use the AMQP::Channel#on_error method as demonstrated below:

events_channel.on_error do |ch, channel_close|
  puts "Channel-level exception on the events channel: #{channel_close.reply_text}"

commands_channel.on_error do |ch, channel_close|
  puts "Channel-level exception on the commands channel: #{channel_close.reply_text}"

Defining channel-level exception handlers will reveal many issues that it might take more time to detect using other troubleshooting techniques.

Testing network connection with AMQP broker using Telnet

One simple way to check network connection between a particular network node and a node running an AMQP broker is to use `telnet`:

telnet [host or ip] 5672

then enter any random string of text and hit Enter. The AMQP broker should immediately close down the connection. Here is an example session:

telnet localhost 5672 Connected to localhost. Escape character is '^]'. adjasd AMQP Connection closed by foreign host.

If Telnet exits after printing instead

telnet: connect to address [host or ip]: Connection refused telnet: Unable to connect to remote host

then the connection between the machine that you are running Telnet tests on and the AMQP broker fails. This can be due to many different reasons, but it is a good idea to check these two things first:

Broker Startup Issues

Missing erlang-os-mon on Debian and Ubuntu

The following error on RabbitMQ startup on Debian or Ubuntu

ERROR: failed to load application os_mon: {"no such file or directory","os_mon.app"}

suggests that the erlang-os-mon package is not installed.


This guide was written by Michael Klishin and edited by Chris Duncan

Tell us what you think!

Please take a moment to tell us what you think about this guide on Twitter or the Ruby AMQP mailing list

Let us know what was unclear or what has not been covered. Maybe you do not like the guide style or grammar or discover spelling mistakes. Reader feedback is key to making the documentation better.

If, for some reason, you cannot use the communication channels mentioned above, you can contact the author of the guides directly