On Aug 2, 2006, at 1:30 AM, Meeraj Kunnumpurath wrote:
Jeremy,
Ok, this is my suggestion ...
1. Have an annotated destroy method on the ThreadPoolWorkManager that
will shutdown the executor. I tried this, however, for some reason the
destroy method is not getting called. Is there anything else I need to
do apart from the @Destroy annotation on the method?
I'll take a look at this today and see why it's not called.
2. Mark the threads as daemon. We can easily do this, as the Eexcutors
class has an overloaded factory method where we can specify a thread
factory.
Ta
Meeraj
-----Original Message-----
From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
Sent: 02 August 2006 00:49
To: meeraj; Meeraj Kunnumpurath
Subject: Re: Problem with suplly chain
On Aug 1, 2006, at 4:14 PM, meeraj wrote:
For some reason the list seems to be bouncing my emails from my
internet email account.
I can forward messages to the list if that would help.
I have managed to reproduce the 'hanging' issue with the supply
chain example on a dual-core machine. It is not really a race
condition, rather the JVM doesn't exit if the thread pool is not
shutdown. This still doesn't explain the issue with the illegal
state exception on single core machines. However, I haven't looked
at it any detail.
Sounds like the pool contains threads that are not marked as being
Daemon threads. I'm not sure how the threads are being created but
perhaps there is a way to make the initial thread a daemon or to make
sure that all threads that we use get marked that way.
There is no shutdown method in either JCA or commonj work managers.
This makes it difficule to add the shutdown behaviour as part of
the contract for the work scheduler abstraction. However, doing a
System.exit() in the finally block in the launcher, the VM does
exit after running the sample. However, we also need to look at the
implications of not shutting down the thread pool in other host
environments.
If it is our implementation then we should be able to shut it down in
a @Destroy method. Shutdown should do something like refuse to accept
new work and allow any returned threads to exit. I don't think
calling System.exit() is a good option.
If we don't own the work manager then we should leave shutdown to the
host environment.
An alternative is to add the shutdown behaviour as part of the work
scheduler abstraction and link it to the waitForAny on the commonj
work manager for jsr237 work scheduler implementation and invoke
that as part of runtime shutdown. However, there is no
corresponding method on the JCA work manager. I am not sure I quite
like this as it is not the intended usage for waitForAny.
Yeah, that sounds fishy.
A third alternative is for ThreadPoolWorkManager to have an
annotated method that is not part of the common abstraction to be
invoked as part of the runtime shutdown. I thought, that was the
purpose of @Destroy annotation. I tried it to shutdown the thread
pool. However, it didn't seem to work.
I think that's what I was suggesting above ;-)
It is quite late for me now, if you could pls copy your thoughts to
[EMAIL PROTECTED], I will take a look tomorrow morning.
Thanks, G'Night.
--
Jeremy
This message has been checked for all email viruses by MessageLabs.
*****************************************************
You can find us at www.voca.com
*****************************************************
This communication is confidential and intended for
the exclusive use of the addressee only. You should
not disclose its contents to any other person.
If you are not the intended recipient please notify
the sender named above immediately.
Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX
This message has been checked for all email viruses by MessageLabs.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
