[rabbitmq-discuss] dotnet client background thread

Fri Dec 16 14:43:52 GMT 2011

This is a really interesting point. Lots of systems have a "vetoable
shutdown about to happen", "non-vetoable shutdown about to happen",
"non-vetoable shutdown imminent" set of events:

   - Unix traditionally used wall(1)
   - Windows and OS X apps ask you "Save this document before quitting?"
   - OS X on shutdown or restart gives apps a chance to abandon or delay
   the shutdown

Stepping back from the immediate problem, the "real" solution is to have
the JVM and .NET virtual machines grow up and behave like proper systems,
complete with lifecycle events. Then, AMQP connections have a chance to
clean up and disconnect on their own, without special action on the part of
the programmer and without unduly delaying or preventing VM shutdown.

Thinking on it, lifecycle events like these are probably already present in
the .NET world actually. Does anyone know where to look?

Cheers,
  Tony

On 16 December 2011 08:27, Simon MacMullen <simon at rabbitmq.com> wrote:

> 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<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<rabbitmq-discuss at lists.rabbitmq.com>
>> https://lists.rabbitmq.com/**cgi-bin/mailman/listinfo/**rabbitmq-discuss<https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss>
>>
>
>
> --
> Simon MacMullen
> RabbitMQ, VMware
> ______________________________**_________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.**rabbitmq.com<rabbitmq-discuss at lists.rabbitmq.com>
> https://lists.rabbitmq.com/**cgi-bin/mailman/listinfo/**rabbitmq-discuss<https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111216/4c491181/attachment.htm>