Forgot to add that the component ref should be nulled at the end of 2...
Jim
On Aug 2, 2006, at 8:48 AM, Jim Marino wrote:
o.k. Actually it looks like it is a problem with both. The issue
is the launcher is not shutting down the system composite (it does
shut down the runtime though). There is a simple fix to this in
Launcher involving:
1. Changing line 116 to make the variable a field on the class:
// deploy the component into the runtime under the system
parent
component = (CompositeComponent<?>) bootDeployer.deploy
(parent, moduleDefinition);
2. and then changing shutdown runtime to:
public void shutdownRuntime() {
if (component != null){
component.stop();
}
if (runtime != null)
runtime.stop();
runtime = null;
}
We may want to have runtime.stop() shut down the system component
although I guess the system could be stopped and restarted without
the runtime stopping. What do people think?
Normally, I would have just applied the fix but I'm in the middle
of some other uncommitted work I can't separate out. Do you mind
checking this out when you get a chance to see it behaves properly
with the work manager changes and then submitting a patch?
Thanks,
Jim
On Aug 2, 2006, at 8:36 AM, Meeraj Kunnumpurath wrote:
From the launcher.
-----Original Message-----
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 02 August 2006 16:10
To: [email protected]
Subject: Re: Problem with suplly chain
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]
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
