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]
