OK - thought so. Figured we could keep the singleton, but reference count the connections so that when no more connections are open we close down the threadpool. (e.g. so we don't leave threads around after undeploying a WAR).
On 8/3/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:
Yeah the idea was it acts as a thread pool. I'm not sure why you would want multiple thread pools. Also if you are in use case where you want to avoid the context switches, there is a System property you can use which causes thread pooling to be disabled and dedicated threads are assigned to each task. Regards, Hiram On 8/3/06, James Strachan <[EMAIL PROTECTED]> wrote: > I'm just investigating a Lingo test case (LINGO-22) submitted by Jim > Beattie which tests that we leave no threads around after shutting > down lingo & ActiveMQ - which sounds good to me. > > I've noticed that the Executor for all connections is a static and > shared across connections. I was gonna make it so that after all > connections are closed all threads are cleanly shutdown - I've a > refactor of Jim's test case to test for this. > > I just wondered before I go ahead and change things - was there a good > reason to keep the TaskRunnerFactory / Executor a singleton? I was > thinking of creating one per connection. Failing that we could keep it > a singleton and just reference count the connections so we can close > it when the last connection goes away > > Am wondering if this was an optimisation to minimise context switching > when using lots of sessions - or is it just an oversight? > -- > > James > ------- > http://radio.weblogs.com/0112098/ > -- Regards, Hiram Blog: http://hiramchirino.com
-- James ------- http://radio.weblogs.com/0112098/
