On 8/1/12 11:56 AM, David M. Lloyd wrote:
> 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.
OK. I will add one.
>
>> 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.
Right. Let's stick with what you suggested then unless others have other
ideas. We should add to the spec requiring that application component
providers should check for the shutdown condition when the thread is
interrupted and try to wrap up the task as soon as possible if
isShutdown() is true.
Should we extend this requirements on setting the isShutdown() flag for
MES and MSES as well?
Regards
Anthony
>
>> > 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?
>>>
>>
>
>