Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Fixed
-
0.24
-
None
Description
I setup a test with the following scenario:
<server> installed rabbitmq-server
<server> installed qpidd
<server> started rabbitmq-server
<client> installed qpid_messaging gem
<client> installed amqp gem (rabbit)
<client> attempt to open connection to qpid
In this scenario, the qpid client code outputs:
2013-10-22 08:36:10 [System] error Caught exception in state: 3 with event: 1: Unsupported version: 0-9 supported version 0-10 (/builddir/build/BUILD/qpid-0.24/cpp/src/qpid/client/TCPConnector.cpp:290)
2013-10-22 08:36:10 [Client] warning Connection [10.13.129.81:33053-10.13.128.23:5672] closed
After this output, it throws a generic MessagingError:
#<MessagingError: Failed to connect (reconnect disabled)>
The problem is that by the time my ruby code catches the exception, the underlying reason for the connection failure has been lost. My ruby code never learns that the reason for the connection failure is because of a server amqp version mismatch.
Take another scenario:
<server> stop rabbitmq-server (now, no amqp service is running)
<cilent> attempt to open connection to qpid
In this scenario, the qpid client code outputs:
2013-10-22 08:38:55 [Network] warning Connect failed: Connection refused
2013-10-22 08:38:55 [Client] warning Connection closed
After this output, it again throws a generic MessagingError:
MessagingError: Failed to connect (reconnect disabled)
It's impossible to tell from the exception thrown by the qpid client whether the underlying connection problem is because there is no service listening on the amqp port, or whether there is a service listening but it implements a different version of the amqp spec.