Quick question: Are you running this from the launcher or SCATestCase?
Jim
On Aug 2, 2006, at 7:28 AM, Meeraj Kunnumpurath wrote:
Ta
-----Original Message-----
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 02 August 2006 15:24
To: [email protected]
Cc: Jeremy Boynes
Subject: Re: Problem with suplly chain
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]
This message has been checked for all email viruses by MessageLabs.
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]
