[rabbitmq-discuss] nonblocking py-amqplib issues
dmitriy.samovskiy at cohesiveft.com
Tue Nov 25 16:20:14 GMT 2008
> console #1:
> $ ./rec_2.py (this is the attached code)
> <I pressed ctrl+z to suspend the program>
> + Stopped ./rec_2.py
> console #2:
> $ ./demo_send.py 1 (standard amqplib demo program)
> $ ./demo_send.py 2
> back to console #1:
> $ fg (to resume the program)
> Traceback (most recent call last):
> File "./rec_2.py", line 31, in <module>
> File "build/bdist.linux-i686/egg/amqplib/nbclient_0_8.py", line 176, in nbloop
> File "build/bdist.linux-i686/egg/amqplib/nbclient_0_8.py", line 74, in write
> <P�' read_buf='&<!amq.ctag-rdYQarPUansf8+2dGsnFAQ==�6<<!amq.ctag-rdYQarPUansf8+2dGsnFAQ==myfan2<�
> text/plainfooIbarSbaz�2�' read_p='175'
I was not able to reproduce this problem with python2.5 on debian etch, but I will revisit
code to see what may be causing it.
> 2. Order of the messages is wrong.
> I just changed the callback function and disabled basic_ack:
> ['4', '1', '2', '3', '4']
I was able to reproduce this problem, and will look into it. It's not only the order but
also looks like client calls callback() more than once for some messages, which would be
> 3. no_ack option for basic_consume is not working.
> With disabled basic_ack, and added no_ack to basic_consume:
> ch.consumer_tag = ch.basic_consume(qname, callback=callback, no_ack=True)
> I get exactly the same results as before.
May I ask what was the expected outcome? With no_ack=False, if your consumer doesn't ack
and disconnects, unack'ed messages will be requeued for another consumer. With
no_ack=True, broker automatically marks all messages it sends to your consumer as ack'ed.
In other words, I think you won't see any difference in output from your script whether
you use no_ack=True or no_ack=False, because they affect requeueing *after* your script
I will see if I can find time to look into the issues above in the near future, but can't
offer any guarantees.
More information about the rabbitmq-discuss