ebin123456 / py-amqplib

Automatically exported from code.google.com/p/py-amqplib
GNU Lesser General Public License v2.1
0 stars 0 forks source link

AMQPChannelException 404 no excahnge AND AMQPConnectionException 503, second 'channel.open' #46

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Which version of amqplib are you using?
0.6.1-1
Have you checked to see if there is a newer version in the "Featured
Downloads" section of the front page of this project?
Yes
Which broker are you using (RabbitMQ?) which version?
2.6.1
Which version of Python?
2.7
What steps will reproduce the problem?
It seems some race condition, sometimes I can see the 2 exception in my log 
file.

What is the expected output? What do you see instead?
The expected behavior is to publish a message but the publishing process dies 
after the exception

Please provide any additional information below.
I can see those 2 exception in the log file of my application using py-amqplib 
through kombu library.
The strange thins is that the first exception is:
<class 'amqplib.client_0_8.exceptions.AMQPChannelException'>, 
AMQPChannelException(404, u"NOT_FOUND - no exchange 
'55f1152e2ca14745a9f85393bc24f5b4' in vhost '/nova'", (60, 40), 
'Channel.basic_publish')

and then there is the other exception:
<class 'amqplib.client_0_8.exceptions.AMQPConnectionException'>, 
AMQPConnectionException(503, u"COMMAND_INVALID - second 'channel.open' seen", 
(20, 10), 'Channel.open'

but if I check in the rabbitmq I can see the exchange.

Unfortunately this problem occurs intermittent and it's difficult to debug, 
maybe the 1.0 version can have a fix to that problem?
Thanks

Original issue reported on code.google.com by andrea.rosa on 24 Nov 2011 at 10:09

GoogleCodeExporter commented 9 years ago
I've found the same issue (but in 1.0.2 version of the library).

More details:

In nova code there are 2 calls one by one:

...
self.channel.close()
self.channel = self.connection.channel()
...

where channel is amqplib.client_0_8.channel.Channel instance

My guess is that that close method returns before the channel was actually 
closed and that is because the second call fails. I've put a sleep call between 
this two calls:

...
self.channel.close()
import time
time.sleep(0.1)
self.channel = self.connection.channel()
...

and after this the error disappeared.

Original comment by maslenni...@gmail.com on 6 Feb 2012 at 11:39

GoogleCodeExporter commented 9 years ago
I don't think the client would be returning too soon here, Channel.close() is a 
synchronous call that waits for the broker to return close_ok.

If I had to guess, I'd say the client is trying to re-use a channel number 
before the broker is really ready for it to be re-used.  But if you put in a 
sleep call, the broker is maybe given enough time to clean up things on its end 
???

If that's the case, then I'd say it's a bug on the broker side, but the client 
could be tweaked to try avoid re-using recently closed channel numbers and see 
if that helps.  

Can you give this patch a try and see if it works around the problem?

Original comment by barry.pe...@gmail.com on 6 Feb 2012 at 5:16

Attachments:

GoogleCodeExporter commented 9 years ago
Hi

yes me too I think that the issue is the client code.
Thanks for this reply

Original comment by andrea.rosa on 7 Feb 2012 at 1:22

GoogleCodeExporter commented 9 years ago
Any feedback on the patch I attached to comment #2?   Was wondering if it 
actually fixed the reported problem.

Original comment by barry.pe...@gmail.com on 10 Mar 2012 at 2:54

GoogleCodeExporter commented 9 years ago
My issue was due to a problem in the client side. UInfortunately at this moment 
I can try your fix.
Regards

Original comment by andrea.rosa on 16 Mar 2012 at 9:20