Hi David,
Thanks for the reply.
I agree that we should specify the shutdown mechanism of
ManagedThreadFactory. How about doing the following:
1) Add a new interface (called ManagableThread?) with a isShutdown()
method. Threads return from ManagedThreadFactory.newThread() should
implement this interface, and
2) Update section 3.4.4 to
- If the ManagedThreadFactory instance is stopped all threads that
it has created using the newThread() method are interrupted and any call
to the isShutdown() method on the ManagableThread interface should
return true.
On the issue of threads starting after the ManagedThreadFactory has shut
down. What about letting the thread start but instead of relying the
user task to check for the isShutdown() thread and do the right thing,
could the Java EE container throw an exception (perhaps an
IllegalStateException)?
> It does raise an interesting question though: can more than one
component use the same managed thread factory/managed executor?
Yes
Regards
Anthony
On 7/30/12 3:47 PM, David M. Lloyd wrote:
> On 07/30/2012 05:28 PM, Anthony Lai wrote:
>> Hi David,
>>
>> Please see inlined:
>>
>> On 7/23/12 8:26 PM, David M. Lloyd wrote:
>>> Sorry, fixed subject line...
>>>
>>> On 07/23/2012 10:24 PM, David M. Lloyd wrote:
>>>> According to the Javadoc at [1], support for managed thread
>>>> factories is
>>>> intended. I am wondering if any particular shutdown mechanism has been
>>>> specified? How will the container tear down threads associated with a
>>>> given component?
>> The spec does not specify how ManagedThreadFactory instances are shut
>> down. I would imagine that the container would have some method in its
>> ManagedThreadFactory implementation class that would be called to
>> shutdown the ManagedThreadFactory instance. Each of those instance would
>> maintain a list of its threads and each of these threads would be
>> interrupted during shutdown.
>
> I think it's important to specify because people who implement threads
> will have to understand the conditions under which they must terminate.
>
>>>> I would like to suggest that we specify a thread base class or
>>>> interface
>>>> for managed threads, which includes an isShutdown() method which would
>>>> return a flag which is set when the thread is requested to terminate.
>>>> The thread should also be interrupted at this time.
>> Could you explain how this new interface method will be used during
>> shutdown? Thanks.
>
> It would be a simple flag that indicates a shutdown is pending that
> the user thread can read in response to interruption. This is
> necessary because thread interruption is a general-purpose mechanism
> which users may choose to leverage to interrupt individual work units
> or for other purposes. The user thread must be able to determine
> whether there is a shutdown pending before they can safely clear the
> interrupt status of the thread.
>
>>>> I would also suggest that threads started after component shutdown was
>>>> initiated should be allowed to run, but they should start with an
>>>> interrupted status and their shutdown flag set.
>> Would the intention for this be to allow creation of new threads for
>> various resource cleanup during component shutdown?
>
> No - it is intended to recognize the reality that one can create a
> thread with a ThreadFactory yet not start it until an arbitrarily
> later time. The only options to avoid problems in this case would be
> to either implement my aforementioned solution or to eliminate the
> concept of a user ThreadFactory, and replace it with some other
> construct which returns a started thread, else creating threads and
> not starting them will evade the container lifecycle.
>
>> If the
>> ManagedThreadFactory belongs to the same component, would this mean we
>> are requiring ManagedThreadFactory to be shutdown last during a
>> component shutdown?
>
> Shutdown order is tricky because it depends on what the thread is
> doing. It might be best to leave the timing up to the container -
> logically you'd probably shut down the managed threads after any
> dependent parties have shut down.
>
> It does raise an interesting question though: can more than one
> component use the same managed thread factory/managed executor?
>