[rabbitmq-discuss] dotnet client background thread
tonygarnockjones+rabbitmq at gmail.com
Fri Dec 16 14:52:26 GMT 2011
The ProcessExit event of System.AppDomain.CurrentDomain might be what's
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?
> 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:
>>> 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>
>> Simon MacMullen
>> RabbitMQ, VMware
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.**rabbitmq.com<rabbitmq-discuss at lists.rabbitmq.com>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss