Responses inline.
On 08/01/2012 01:13 PM, Anthony Lai wrote:
> 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.
OK, but in this case there should be a static "isShutdown()" method on a
utility class somewhere which accesses the current thread, casts it to
the appropriate interface, and returns the value of this method, so that
users can easily poll this flag.
> 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)?
You mean, throw the exception at the time the thread is started? If so,
that doesn't wholly solve the problem: starting a thread just before it
would be shut down can be practically indistinguishable from starting a
thread just after it is shut down. The user code will still have to
detect an immediate interrupt/shutdown condition, and thus it should be
well-documented. A user worker thread which executes tasks for example
would want to clear interrupt status and check the isShutdown flag
before processing each task.
> > 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?
>>
>
--
- DML