ruby-amqp/bunny — Issue #30: possible frame parsing bug
Author: edraut
Created: 2011-12-02 19:23:27+00:00
State: open

We've noticed that in high-message-volume situations with multiple processes connecting to a RabbitMQ node via Bunny, Client#check_response is receiving unexpected values, e.g. plain integers, that cause failures when attempting to create a queue. In moderate volume situation we rarely see this problem, though we have found instance in our logs beginning with our first usage of bunny.

The code is pretty basic, start bunny with connection options, create a queue with no options, write to an exchange passing the created queue as the reply queue. I doubt there's anything special about our implementation as it works perfectly almost all the time, only failing when we run cron jobs that have multiple workers all sending/receiving messages via bunny for many minutes at a time.

It seems odd to me that Client#check_response would receive a value of 2 rather than the expected DeclareOK or some other standard AMQP response. If I'm wrong and our implementation could be to blame please let me know, but I suspect a frame parsing bug in Bunny.

Another detail: once it starts getting bogus values in Client#check_response, it continues to get bogus values, as though the buffer sequencing has gotten shifted causing all frames to be incorrectly parsed.

So, could this be a bug in Bunny? If so, what do you need from us to help reproduce it?

Thanks,
Eric