Proper disposal of listenerContainer and such

[zvolkov]

Another newbie question. Under what circumstances would I explicitly dispose my stuff like below, vs. relying on the framework? I understand I need them if I want to control their lifetime in advanced scenarios but it would help if I new the default behavior and the rule of thumb.

listenerContainer.Stop();
listenerContainer.Shutdown();
contextRegistry.Clear();

[zvolkov]

So far it looks like you need to call listenerContainer.Stop() to stop the listener threads otherwise the process won't shutdown (uses non-background threads?) and ContextRegistry.Clear() not sure exactly why. What is listenerContainer.Shutdown() then?

[Mark Pollack]

Hi,

There was a bug (http://jira.springframework.org/browse/SPRNET-1153) that was fixed when stopping the container - it would hang. You may want to get the nightly build (http://www.springframework.net/downloads/nightly/) which fixes this bug. This bug fix will be included in the 1.2.1 release.

Cheers,
Mark

[zvolkov]

This is nice to know. Now, what about the actual question, is there any guidance on the subj or I guess I just need to RTFC...

[Mark Pollack]

Hi,

Ha, sorry, I actually missed reading the first post. Doh!


Another newbie question. Under what circumstances would I explicitly dispose my stuff like below, vs. relying on the framework?

If what you want is to have your messaging server start dispatching messages off the queue when the process starts and stop when the process ends, then you can rely on the 'new context/context.dispose' to handle the lifecycle of the message listener container. That is because the message listener container is in singleton scope and kept track of by the spring context. When the container is disposed it iterates over all singleton scope objects and calls a destruction callback function. Generally speaking, the callback is either IDisposable's dispose method or a no-arg method of your choice set via the 'destroy-method' XML element in the Spring configuration.

As you mention, for more advanced cases, say 'starting' and 'stopping' the container multiple times in the same running process, methods on the listener class can be used. I would recommend using Shutdown and Initialize to recycle the message listener container.

There is little practical difference at the moment in the MQMQ listener container between initialize/shutdown and start/stop. The idea behind having seperate methods is that Initalize and Shutdown are responsible for allocating resources and required infrastructure for processing messages, for example setting up a threading pool or making a connection to a messaging daemon. (The latter is more relevant for JMS style APIs than MSMQ). The start/stop methods are to control message dispaching only.


Hope that helps.

Cheers,
Mark

[rpaterlini]

Even using the latest build, the problem is not completely resolved.

I think it is better to explicitly stop all threads (calling listenerContainer.Shutdown()) before calling context.Clear(), to make sure that they do not use objects managed by Spring.NET that could be already disposed.

The same is also valid for other threads used by the process.

[Mark Pollack]

Hi,
The current implementations of AbstractPeekingMessageListenerContainer do not use any other resources of singleton scope so relying on context.dispose is OK. For other subclasses, this could be different as well as future changes to the current implementations, so I'll take it back and say that it would be better practice to code defensively in this case and call shutdown first.

Cheers,
Mark

[zvolkov]

Got it, thanks Mark. My experience with 1.2.0 was, unless I call .Stop(), the .Shutdown() blocks indefinitely, so I'd rather do Stop followed by Shutdown than Shutdown alone like you say. Once again it could just be 1.2.0.