[rabbitmq-discuss] CRITICAL:pika.connection:Attempted to send frame when closed

Tue May 27 13:49:14 BST 2014

Thank you for the detailed understanding of the issue and the speedy 
reply. :)

Yes, there are multiple queues, thus multiple consumers.
However yeah, I understand that the read is happening faster than write. 
I tried using delays to level it up. didnt work!
I can assure the network's fine here.

The Rabbit log has the following:

=ERROR REPORT==== 27-May-2014::17:19:41 ===
AMQP connection <0.6238.0> (running), channel 1 - error:
{amqp_error,unexpected_frame,
             "expected content header for class 60, got non content 
header frame instead",
             'basic.publish'}

=INFO REPORT==== 27-May-2014::17:19:41 ===
closing AMQP connection <0.6238.0> (127.0.0.1:35918 -> 127.0.0.1:5672)

Thus it closes the connection after the unexpected frame error.

On Tuesday 27 May 2014 05:59 PM, Michael Klishin wrote:
>   On 27 May 2014 at 16:24:19, shilpa karkera (shilpa.karkera at finoux.com) wrote:
>>> And the other queues also run well till some amount of time while
>> the
>> first queue gets this error and stops producing consuming. Consequently
>> others follow to the same warning in some time.
>> This is the only thing that comes up when a queue has gone dead:
> These lines suggest your program opens multiple connections to RabbitMQ:
> https://github.com/haridas/RabbitChat/blob/master/tornado_webapp/rabbit_chat.py#L54-56
>
> is this the case? If so, then it's no surprise that some consumers continue to function
> (if that's what "first queue gets this error and stops producing consuming" means): their
> connections are open and fine.
>
>> When i use PIka version: 0.9.13 This is the error:
>>   
>> CRITICAL:pika.connection:Attempted to send frame when closed
>>   
>> When I tried with 0.9.14 (latest 1 from the git): This is the error:
>>   
>> Pika: Write buffer exceeded warning threshold at 555752 bytes
>> and an
>> estimated 6861 frames behind
> The message says that it is *write* buffer that is behind
> (presumably because connection is down). Or it may be a red herring,
> I'd investigate other possible reasons first.
>
> What's in RabbitMQ log?
> --
> MK
>
> Software Engineer, Pivotal/RabbitMQ
>
>