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 progress
Date Fri, 23 Jul 2010 20:07:12 GMT
On 7/22/2010 12:10 PM, Gregg Wonderly wrote:
> I'm thinking more and more that this runAfter business should really be
> a O(1) thing. If runAfter() is implemented to return true, can not that
> decision be made at the time of enqueue? It just looks like so much of
> this is spread around to so few actual users in the current API. As I
> look over the usages, there is some fuzzy logic involved in some cases
> where the sequence number is used for ordering.  ...

I think some of the sequence number stuff may be OK, but if it is OK it 
is probably unnecessarily inefficient.

RetryTask is a widely extended abstract class that implements 
TaskManager.Task. It provides for automatic retries of failed attempts 
where failure is defined by the result of a call to a boolean-value 
method tryOnce that makes a single attempt.

It does not supply a runAfter.

I *think* some of the RetryTask subclasses have a requirement to not 
make their first attempt until some preconditions are met by completion 
of other tasks. When there is a retry, younger and irrelevant tasks may 
have entered the TaskManager, but the preconditions were already 
achieved on the first try.

If this is really what is going on, maybe runAfter should be different 
on first and subsequent tries. For example, RetryTask might supply a 
runAfter that calls an overloaded version with an additional parameter 
indicating if it is a first attempt or a retry.

I need to study this some more, to make sure it is only being used 
correctly.

I've suspended work on TaskManager itself in order to write an analysis 
of its callers, with a view to wider scope refactoring.

Patricia


Mime
View raw message