[rabbitmq-discuss] dotnet client background thread

[Simon MacMullen]

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 
broker.

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.

Cheers, Simon

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:
> http://msdn.microsoft.com/en-us/library/system.threading.thread.isbackground.aspx
>
> 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
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss


-- 
Simon MacMullen
RabbitMQ, VMware