[rabbitmq-discuss] Stuck waiting for frame during amqp_basic_qos?

Wed Nov 9 22:48:02 GMT 2011

Pieter,

Just a bit off topic… where's the source code for this extension? What's the official repo?

Cheers,

Alvaro

On Nov 9, 2011, at 11:46 PM, Pieter de Zwart wrote:

> Awesome! That makes a lot of sense. I will rejigger my code to check all
> RPC calls, there really is no reason I did not do that earlier apart from
> sheer laziness =)
> 
> Thanks!
> me
> 
> 
> 
> 
> 
> On 11/9/11 2:19 PM, "David Wragg" <david at rabbitmq.com> wrote:
> 
>> Hi Pieter,
>> 
>> Pieter de Zwart <pdezwart at rubiconproject.com> writes:
>>> I have managed to reproduce it using C code only. Caveat: this code is
>>> really messy and leaks like a sieve.
>>> 
>>> Let me know what you think. And please don¹t judge me =)
>> 
>> Thanks.  That was very helpful to work out what is going on here.
>> 
>> Here's the tracer output with your program:
>> 
>> [...]
>> 1320874543711: <Tracer-0> ch#1 ->
>> {#method<basic.ack>(delivery-tag=22,multiple=true),null,""}
>> 1320874543711: <Tracer-0> ch#1 ->
>> {#method<basic.qos>(prefetch-size=0,prefetch-count=3,
>> global=false),null,""}
>> 1320874543752: <Tracer-0> ch#1 <- {#method<channel.close>(reply-code=406,
>> reply-text=PRECONDITION_FAILED - unknown delivery tag 22, class-id=60,
>> method-id=80),null,""}
>> 1320874543791: <Tracer-0> ch#1 ->
>> {#method<basic.qos>(prefetch-size=0,prefetch-count=1,
>> global=false),null,""}
>> 
>> The client sends the bad ack, and immediately follows up with the
>> basic.qos.  That first amqp_basic_qos call after the ack does return
>> NULL to indicate an error, although your program doesn't report that
>> error.
>> 
>> Then your program does another basic.qos.  And the server never replies
>> to it.  That's actually what the AMQP spec requires: Once a peer sends a
>> channel.close, it should ignore all frames on that channel except the
>> channel.close-ok indicating that the channel is fully closed.
>> 
>> However, librabbitmq never sends a channel.close-ok, and in fact provides
>> no way to do so.
>> 
>> That seems like a bug in librabbitmq to me.  But I'll have to have a
>> think about the best way to fix it.
>> 
>> In the meanwhile, you should always check for errors from API calls.
>> When you get an error, you should not re-use the relevant channel.  And
>> if your connection is potentially long-lived, that means that you should
>> probably close and re-open it.
>> 
>> -- 
>> David Wragg
>> Staff Engineer, RabbitMQ
>> VMware, Inc.
> 
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

Sent form my Nokia 1100