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

[Matt Pietrek]

Thanks Alan. After posting this, and doing some additional digging around,
I also uncovered the AMQP spec portion that indicates an AMQPChannelError
can result in a closed channel.

FWIW, I subsequently tried to detect this condition and reestablish the
channel before subsequent uses. However, I ran into problems with Pika
0.9.5, wherein the old channels hung around. Subsequent digging turned up
that there was a bug in Pika 0.9.5 where the correct response isn't set
back to the server in this situation.

Switching to 0.9.6pre, I got further (at least I could close the old
channel without hanging.) However, there was still enough issues that I
backed off to a more brute force solution - If the channel receives an
exception, I simply kill the connection and reestablish a new connection
and channel. Probably not optimal, but it seems more reliable.

Matt


On Wed, Mar 28, 2012 at 11:14 AM, Alan Antonuk <alan.antonuk at gmail.com>wrote:

> I can't tell you why its hanging, but in general when a channel throws an
> exception, the channel is closed (its how the AMQP protocol works).  Trying
> to use the channel after a channel exception (or any closed channel) will
> result in connection exception which will shut down the entire connection.
>
> -Alan
>
> On Wed, Mar 28, 2012 at 2:04 PM, Matt Pietrek <mpietrek at skytap.com> wrote:
>
>> 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
>>>
>>
>>
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120328/9a899217/attachment.htm>