[rabbitmq-discuss] debugging an unroutable message

Daniel Risacher magnus at alum.mit.edu
Tue Mar 30 11:44:32 BST 2010


I did have some race conditions in the first pass of the code, but I
think that's fixed before I wrote to the list.  Generating the 'ping'
happens as part of a $queue->do_when_created() callback.  I'm
certainly not explicitly changing the ack settings or QoS settings.

I actually fixed my example by not binding the reply queue to
amq.direct, and instead using the default binding to the unnamed
default exchange.  Which is good in that I can move forward on other
parts of my project, but one of the secondary goals of the project is
to learn about how AMQP works in implementation, and I still don't
understand what was wrong with the first approach.

I never delete queues - I let the server do that when the connection drops.

I suppose there could be another race between the bind to amq.direct
and the pong.  I wasn't explicitly waiting for bindOK, although as I
recall from the traces, I was getting bindOK, before sending the ping,
and it still wasn't working - but I'll check that.

Are there rules about what can be bound to amq.direct?

It would be useful if there were some way to have rabbitmq output
every transaction (in commit order?) for analysis/debugging. Is there
any mechanism to do something like that?  Maybe as a plugin?

On Tue, Mar 30, 2010 at 5:28 AM, Matthew Sackman <matthew at lshift.net> wrote:
> Hi Daniel,
>
> On Mon, Mar 29, 2010 at 04:03:22AM -0400, Daniel Risacher wrote:
>> Here's the bug symptom- it strictly alternates between working and not
>> working.  Works the first time, not the second, etc.   When it doesn't
>> work, the daemon gets the PING, but the PONG is returned as
>> unroutable.
>
> Sounds like a race between the pong being sent and the queue being
> created. You're not setting the nowait option on queue.declare are you?
> And you are waiting to get back the queue.declare_ok before sending the
> ping? And under what conditions will the queue be deleted? Also,
> (unlikely to be affecting this) is the daemon and client acking
> explicitly or is noAck set? Any QoS settings?
>
> Matthew
>
>




More information about the rabbitmq-discuss mailing list