Closing connection raises AMQPPreconditionFailed

[kristaps]

Running the example program at https://gist.github.com/kristaps/9985184 and pressing Ctrl-C on both clients causes the client where Ctrl-C was pressed first to throw an exception after a while, the other client seems to complete normally.

The traceback:

^CGot KeyboardInterrupt
Traceback (most recent call last):
  File "insults.py", line 59, in <module>
    conn.close()
  File "/Users/kristaps/.virtualenvs/celery/lib/python2.7/site-packages/rabbitpy/connection.py", line 168, in close
    self._shutdown_connection()
  File "/Users/kristaps/.virtualenvs/celery/lib/python2.7/site-packages/rabbitpy/connection.py", line 466, in _shutdown_connection
    self._channel0.close()
  File "/Users/kristaps/.virtualenvs/celery/lib/python2.7/site-packages/rabbitpy/channel0.py", line 58, in close
    self._write_frame(specification.Connection.Close())
  File "/Users/kristaps/.virtualenvs/celery/lib/python2.7/site-packages/rabbitpy/base.py", line 326, in _write_frame
    raise exception
rabbitpy.exceptions.AMQPPreconditionFailed: <pamqp.specification.Channel.Close object at 0x10eba5750>

The example program should be run something like this:

python insults.py a b
python insults.py b a  # params from the first invocation reversed

I don't see anything obviously wrong in the code, am I missing something?

[gmr]

I do see this behavior, I'm doing some tracing to figure it out. Thanks for the example code, it's very helpful.

[gmr]

It looks like it has to do with how rabbitpy handles received, yet unprocessed messages when closing the channel. I should have a fix for this shortly.

[gmr]

Exact bug was not checking to see if the queue was being consumed in no-ack mode prior to trying to nack any received messages that were unprocessed.

[gmr]

This is fixed in master and will be released as 0.16.0 soon.