[rabbitmq-discuss] Pika channels sensitive to prior operation state?

[Matt Pietrek]

Following up on this problem, I've narrowed the issue down to a trivial
example that hangs:

import pika
HOSTNAME = "192.168.78.18"  # Plug in your own server name here.

if __name__ == '__main__':
    connection =
pika.BlockingConnection(pika.ConnectionParameters(host=HOSTNAME, port=5672))
    channel = connection.channel()

    try:
        method_frame, _, body = channel.basic_get(queue="NotAValidQueue")
    except Exception as e:
        print "channel.basic_get threw %s - This is expected" % (e)
    else:
        print "channel.basic_get unexpectedly did not throw an exception."

    print "Before channel.tx_select - Will hang on next line."
    channel.tx_select()
    print "After channel.tx_select - Unexpectedly got here."

    channel.tx_commit()


On Tue, Mar 27, 2012 at 4:54 PM, Matt Pietrek <mpietrek at skytap.com> wrote:

> I have a Pika 0.9.5. app communicating with a 2.81 rabbitmq-server
> instance.
>
> I'm noticing some odd behavior, and am not sure if it's a problem on my
> end, on rabbitmq's end, or in Pika.
>
> At it's simplest, I'm seeing a call to channel.tx_select() hang. Breaking
> in with the debugger, the stack looks like this:
>
> _handle_read [base_connection.py:151]
> process_data_events [blocking_connection.py:94]
> send_method [blocking_connection.py:244]
> rpc [blocking_connection.py:216]
> tx_select [spec.py:2615]
>
> Stepping for a bit, I see that the code never gets out of the loop in the
> send_method() function.
>
> In ordinary circumstances, my code that calls tx_select() works fine.
> However, in the case where it hangs, an immediately prior call to
> channel.basic_get() has thrown an exception:
>
> 'pika.exceptions.AMQPChannelError'>:(404, "NOT_FOUND - no queue 'foobar'
> in vhost '/'"
>
> I'm baffled. Known issue? Something I'm doing wrong?
>
> Thanks,
>
> Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120328/b2adc54d/attachment.htm>