[rabbitmq-discuss] Problem with Tx.Commit and/or Pika?

[Matthias Radestock]

Matt,

On 16/08/12 19:31, Matt Pietrek wrote:
> I have a simple, single threaded program using Pika's SelectConnection
> with RabbitMQ 2.8.5 that simply listens for request messages and replies
> to them.
>
> This code generally works - It can receive many thousands of messages
> before it croaks. When it does croak, it's with the following error:
>
> *CHANNEL_ERROR - unexpected command while processing 'tx.commit'
>
> *The code looks like this:
>
> def handle_delivery(channel, method, header, body):
>      print "Received message"
>
>      channel.tx_select()
>      channel.basic_publish(exchange="skytap",
>          routing_key='foo.bar',
>          body='reply',
>          mandatory=True,
>          properties=BasicProperties(delivery_mode=2))
>      channel.tx_commit()
>
>      channel.tx_select()
>      channel.basic_ack(delivery_tag=method.delivery_tag)
>      channel.tx_commit()

btw, you only need to call tx_select *once* - once a channel is in tx 
mode it stays in tx mode and the next transactions starts when the 
previous one is committed or rolled back.

> That is, it looks like a Basic.Deliver and a Basic.Publish are sneaking
> in before the Tx.Commit-Ok comes back.

Nothing wrong with the Basic.Deliver, since that travels from the server 
to client. However, seeing a basic.publish (or indeed anything) going 
from from the client to the server after tx.commit has been issued but 
before tx.commit-ok has been received is definitely bad. AMQP does not 
permit the sending of other commands while a synchronous command is 
outstanding.

> I suspect this is a Pika issue, but my reading of the code doesn't show
> any obvious problems.

I don't know pika, but perhaps it is possible for multiple 
handle_delivery invocations to run concurrently?


Matthias.