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

Thu Nov 10 00:34:23 GMT 2011

The source code for the extension is in the PECL SVN repository:
https://svn.php.net/repository/pecl/amqp

We are currently working on the 1.0 release, which has a much different
signature. That code is mainline:
https://svn.php.net/repository/pecl/amqp/trunk

I have a bunch of documentation pending that I can send you as well if you
are interested. I would rather bypass the list though since it is a large
attachment.

me

On 11/9/11 2:48 PM, "Alvaro Videla" <videlalvaro at gmail.com> wrote:

>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
>
>
>