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
