channel starts consuming before I call start_consuming(), then raises Queue.DeclareOk KeyError

[AaronVoelker]

Note: Cross-posted here: http://groups.google.com/group/rabbitmq-discuss/browse_thread/thread/3f39ac9c9d643e64

Environment: Python 2.6.6, Ubuntu 10.10, Pika 0.95. I have reproduced
this problem on several machines with the same specs.

Description of Test: Publish to test1, then consume from test1 and
test2.

What Happens: The queue with the message begins consuming before I
have even told it to start_consuming. Pika seems to get into a weird
state, and then throws a Queue.DeclareOk KeyError.

Error:

In Callback Hello World
Traceback (most recent call last):
  File "./rabbittests.py", line 31, in <module>
    channel.queue_declare(queue=queue_name)
  File "/usr/local/lib/python2.6/dist-packages/pika/spec.py", line 2437, in queue_declare
    [Queue.DeclareOk])
  File "/usr/local/lib/python2.6/dist-packages/pika/adapters/blocking_connection.py", line 221, in rpc
    frame = self._frames[reply]
KeyError: 'Queue.DeclareOk'

The Code:

#!/usr/bin/python

import pika

######### Producer Code

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()

for queue_name in ('test1', 'test2'):
    channel.queue_declare(queue=queue_name)

channel.basic_publish(exchange='', routing_key='test1', body='Hello World')
connection.close()

######### Consumer Code

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()

def callback(ch, method, properties, body):
    print "In Callback", body
    ch.basic_ack(delivery_tag = method.delivery_tag)

for queue_name in ('test1', 'test2'):
    channel.queue_declare(queue=queue_name)
    channel.basic_consume(callback, queue=queue_name)

assert False # this doesn't execute
channel.start_consuming()

[gmr]

Please run the following code:

#!/usr/bin/python
import pika
print pika.__version__

[AaronVoelker]

As stated at the top, I am using Pika 0.9.5 (verified again by pika.version). Thanks.

[gmr]

Thank you for verifying, there have been numerous issues like this where users report they're using the pypi installed 0.9.5 and in fact, are not. I'll try and reproduce your problem.

[AaronVoelker]

Wondering if this was able to be reproduced. I was thinking of trying an alternative method of opening two separate async connections under the same IOLoop. Would this be a viable workaround? Thanks.

[AaronVoelker]

Update: This problem doesn't seem to occur when using a TornadoConnection instead of a BlockingConnection. I have been using this as a workaround for the issue, and have yet to run into any problems.

Edit: Sorry about the repeated close/reopens. I am too used to forums where the "Post" button is the left button, not the right.

[khattori]

I also faced a similar problem.
I found that the problem was caused by BlockingChannelTransport.send_method.
The method should be reentrant.

I propose the following patch:

diff adapters/blocking_connection.py.bak adapters/blocking_connection.py
239d238
<         self.wait = wait
242c241
<         while self.wait and not self._received_response:
---
>         while wait and not self._received_response:

[gmr]

Thanks for the test case, I've been able to reproduced and it is fixed. Sorry for the long delay.