Closed romanlum closed 7 months ago
This is highly unusual to close a channel from within a delivery handling method of its consumer. channel.close
is a synchronous operation, it instructs the channel to wait for a response, while it is in the middle of a channel dispatch.
@lukebakken @Gsantomaggio do we care to address this? Closing in an asynchronous task should be a decent workaround.
To start with I strongly suggest not using AMQP transactions.
Having said that, yes it is probably a Bad Thing™ to close a connection within a delivery handler. Running a new Task should be fine. I'll see if I can come up with a better way to do this, though. I'm thinking you may be able to cancel your consumer and then re-connect when BasicConsume
returns.
Thanks for your quick reply. Can you describe why we should not use AMQP Transactions?
https://www.rabbitmq.com/semantics.html
I've found that people assume AMQP TX provides transactions like those in a database. There are a lot of caveats in that document. If you're aware of them, and are OK with the performance of AMQP TX, then go right ahead.
In general, publisher confirmations are a better solution.
@romanlum I don't think there is actionable work for us to do with this issue.
Please try the following suggestions:
Reconnect
in your message received event handler. Instead, cancel your consumer then set a wait-able condition so that another thread or task can do the reconnection.Async
interface available in version 7 alpha releases, then test in a pre-production environment.
Describe the bug
We are currently have an unexpected behaviour in some rare network error situations.
There is a timeout on TXCommit and after that we are cleaning up the connection and try to reconnect to the rabbitMQ server.
Here is the Consumer_Received method.
The reconnect method closes the Send and Receive Channel and also the Connection. This sometimes results in a deadlock because of the following code:
Is it allowed to close the rabbitMQ connection in the Received Event?
Should we call the disconnect method in another thread?
Thanks for your help
Reproduction steps
Its hard to reproduce the network error that causes the TXCommit to timeout but the TCP connection does not fail.
Expected behavior
Connection.Close should not deadlock.
Maybe there is a missing
ConfigureAwait(false)
atConsumerDispatcher.Shutdown(this).GetAwaiter().GetResult()
; ?Additional context
RabbitMQ Client Version 6.4.0
Callstack of the deadlock