[rabbitmq-discuss] dotnet client background thread

[Tony Garnock-Jones]

The ProcessExit event of System.AppDomain.CurrentDomain might be what's
sought here:
http://msdn.microsoft.com/en-us/library/system.appdomain.processexit.aspx


On 16 December 2011 09:43, Tony Garnock-Jones <
tonygarnockjones+rabbitmq at gmail.com> wrote:

> 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/975bc69a/attachment.htm>