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