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? 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]
