[rabbitmq-discuss] dotnet client background thread
simon at rabbitmq.com
Fri Dec 16 13:27:45 GMT 2011
We've had this argument back and forth a bit for both the Java and .NET
clients. The reason why we've been reluctant to do this is that by
making connections use daemon / background threads we encourage a
situation where connections don't get properly closed when your
application shuts down.
So for example if your application publishes a load of messages and then
exits, if we used background threads then things would appear to work
but there would be no guarantee that all the messages would reach the
So really the right thing to do is explicitly close connections at shut
down - then you know that everything you thought the connections were
doing is actually done.
On 15/12/11 20:53, Eyal Post wrote:
> We have an issue with a .net client application that creates a
> connection in order to publish message and caches this connection in a
> variable. The problem is that when the program exits, it gets stuck in
> memory because there is an AMQP thread that doesn’t exit.
> I’m not sure how the RabbitMQ threads are created but in .net there is
> an option to set a thread as a background thread and in this case when
> the application closes it will not wait for background threads to stop.
> Is the .net client setting the background threads it creates background?
> If not, can you change that?
> See here for more details:
> Eyal Post
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
More information about the rabbitmq-discuss