Closed reisenberger closed 8 years ago
@reisenberger please post questions to rabbitmq-users. Yes, IModel.Close
is what we expect to be used.
@michaelklishin: @reisenberger had one more question: Is it theoretically OK to omit .Close()
entirely? Emile Joubert advised to do so in 2012, does this still apply?
I've done extensive testing, and calling .Close(), .Dispose() or .SafeDispose()
within the ConnectionShutdown
event consistently leads to a deadlock and a connection that never recovers. .Close()
causes it fastest of all. Omitting .Close()
does not lead to broker connection starvation or memory leaks, this suggests Emile Jouberts advise still applies: The Channel/Model/IModel
appears to release its own resources. Can you confirm this?
@sivesind ah, this is in the context of a connection shutdown… then yes, you don't want to use Close
. Dispose
makes sense there although it's basically an equivalent of Abort
. Doing nothing should also be fine.
@michaelklishin: Thanks a lot! This really helped out!
(my practical tests with extensive restarts of RMQ shows that .Dispose()
and .SafeDispose()
also causes deadlocking in EasyNetQ, but that may well be an EasyNetQ issue)
I am an EasyNetQ user assisting another EasyNetQ user on EasyNetQ/EasyNetQ#522 . The investigation of the issue within EasyNetQ seems clearly to point to the problem that
IModel.Dispose()
blocks if called from within theConnectionShutdown
event.We note from 2012 correspondence http://grokbase.com/t/rabbitmq/rabbitmq-discuss/128mwgvyvc/net-rabbitmq-client-issue-deadlock-on-connectionshutdown http://grokbase.com/t/rabbitmq/rabbitmq-discuss/129maqaa6s/imodel-dispose-locks-if-called-during-connectionshutdown-event ... that Emile Joubert suggested:
Does this advice still apply? IE Should EasyNetQ stop calling
Dispose()
onIModel
s within theConnectionShutdown
handler?Or should EasyNetQ follow advice in #49 ? , ie call
.Close()
on theIModel
now, rather than.Dispose()
?Thanks