|
Defines protocol for dealing with Expansions as they change over time.
This follows the expansion lifecycle. When an expansion fails, we get an initial
shot at fixing it. If we can replace all the failed subtasks, then the expansion can
be called "fixed." If it has been fixed, don't report it as failed (we can't change
the reported alloc result, even if we replace all the tasks in the workflow).
If there are still some subtasks in the workflow that we could
not replace, then the expansion is a failure and should be reported as such.
Uses getSubTaskResults, which erases it's logger.info after being called. (Another call
will give an empty list.) It reports on subtask alloc results that have changed.
This breaks down into 6 steps (= each if statement below):
1) Looks for failed subtasks on the expansion, and if finds any, passes them
to listener. handleFailedExpansion gets a chance at removing the failed subtasks
from the expansion's workflow and replacing them with tasks with different prefs.
By default, if the expander can't fix this expansion, it should just report the
failure. If the expander can only fix some of the tasks and not all, it should
report as failure.
2) Then if no subtask failed, but there was a constraint violation, the
listener is told of which constraints were violated.
3) If no subtasks failed, and no constraint was violated, the listener still
has the option of changing the expansion, and if it wants to, will get passed
the expansion.
4) If some subtasks could not be fixed, we may want to report the failed expansion
The problem is that we may then report the failed expansion twice, since we report
it once if it fails and we can't do anything about it in handleFailedExpansion, and
then again after the report in handleFailedExpansion. (The Expansion has changed
with the report->estimated flip (I think)). The second time, no subtask results
are marked as changed.
5) If it's a success, report it.
6) If it's reported as a failure, but has no subtasks that are failures, the
expansion has been handled previously, and we can ignore it.
So for now (01/11/00), we don't automaticaly report this. We may want to revisit
later.
BOZO - 01/11/00 GWFV
Parameters:
exp - Expansion to examine |
