[rabbitmq-discuss] RabbitMQ problem

[Matthias Radestock]

Valentino,

Valentino Volonghi wrote:
>> That would be because the connection has been closed.
> 
> Why? This is completely unexpected to me... Also I don't think this
> is true because I don't see the connection dropped error on the
> client side that I usually see when I stop rabbitmq server.

There are only two ways to report an error to the client in AMQP - the 
server needs to send either a channel.close or connection.close method. 
The client is then expected to respond with a close-ok and at that point 
(or after a timeout) the channel/connection is closed.

Because we do not know the exact reasons for why the commit failed we 
assume the worst, an INTERNAL_ERROR, which, like all severe errors, is a 
connection error, i.e. it will force the connection to close.

> Sure, it's just that dropping the connection because a transaction failed
> makes the commit_failed message completely useless. Just use the
> connection dropped error to mean the same thing, I'm not sure this is the
> right behavior (from a logic point of view).

The server doesn't just drop the connection. It follows the connection 
closure protocol, and as part of that the client is told about the 
closure reasons.

> If a database dropped the connection every time a transaction failed
> they would spend more time off rather than doing anything. That's why
> I think it's an error, after all transactions are isolated and a
> rollback is there exactly to be able to go back to the beginning 
> without any consequences.

I see your point, alas there is nothing in the AMQP protocol, such as a 
tx.commit-fail method, that would allow us to inform the client of the 
tx failure without closing the channel or connection.

This has come up in discussions in the Working Group, so I would expect 
an improvement in this area at some point.

>>> but apparently I don't even receive the failed commit message.
>>
>> That is strange. What client are you using?
> 
> 
> erlang client and rabbitmq server.

In the Java and C# clients the channel and connection closure reasons 
are propagated to the initiators of all pending request-response 
interactions. I am not sure whether that is happening in the Erlang 
client. We will look into it.


Matthias.