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
