river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: TaskManager
Date Sun, 26 Jun 2011 22:16:04 GMT
On 6/26/2011 1:58 PM, Peter Firmstone wrote:
> Patricia Shanahan wrote:
>> On 6/26/2011 1:23 PM, Peter Firmstone wrote:
>>> There's an interesting thread of discussion in the Porter mail archive
>>> that Mark has uploaded for us (see River-311), relating to the
>>> TaskManager.
>>>
>>> Here's a very interesting comment from Bob Scheifler:
>>>
>>> Over the years we've been slowly eliminating use of Task.runAfter, and
>>> in any overhaul I'd prefer to finish that job rather than perpetuate it.
>>> I have in a past life been a fan of deadline scheduling.
>>>
>>> Any thoughts?
>>
>> If it can be done, it might remove one of my concurrency concerns.
>>
>> Some TaskManager tasks have a retry concept. The retry implementation
>> creates a window during which the task is not known to the TaskManager,
>> and is not considered by the TaskManager runAfter testing. I think there
>> may be cases in which the code that submitted the task treats it as
>> having been done before a new task runs, because of runAfter, but that
>> may not be the case, because of a retry.
>>
>> The negative side of this is that the class submitting the tasks would
>> have to have its own mechanism for queuing up tasks that need to run in
>> order.
>
> Perhaps we can provide a utility class or queue for such a purpose,
> something like a BlockingQueue?

I think the way to look at this is to examine the non-trivial runAfter
implementations. If they have common elements that can be helped by some
utility classes, write those classes. If not, deal with each individually.

We are now committed to 1.5, so if we did not have runAfter we could
replace TaskManager with java.util.concurrent.ThreadPoolExecutor.

Patricia

Mime
View raw message