On Wed, Jul 15, 2009 at 02:15, Fan Dong<[email protected]> wrote:
> How do I tell the workflow to stop when an error raised from one of the
> processors?
>
> In my case, all processors are JAX-WS web services. During an experiment, I
> found the workflow just went ahead despite an essential processor failed.
> What I mean essential processor is that the process the rest of the
> processors depend on (or run after). What I mean fail is that the icon of
> that processor turned red and exceptions thrown out.
What you are talking about is implemented in Taverna 1 as 'Set as
critical'. You can tick the 'Critical' box next to the processor in
the Advanced Model Explorer. In the attached workflow "echo_list1"
should never run, as always_fail will always fail - and the
sleepy_echo processor has a 500 ms delay. The processors above
sleepy_echo might or might not run, as they run in parallel to
always_fail and echo_list3, which will never run.
In Taverna 1, a nested workflow which has a processor marked as
critical would also itself fail, so it would never give any outputs
and can hence either be set as critical in the parent workflow, or set
with a 'retry' - which was often used as a way to generate loops. (A
feature now built-in directly in Taverna 2 - under Advanced -> Looping
on selecting a processor's details - see
http://www.mygrid.org.uk/advanced-contextual-view/loop-configuration/
)
This Critical feature has not yet been introduced to Taverna 2
(because it's slightly more complicated there, as processor ahead
could have partially started when the upstream error occurs), but it
has been noted as a bug:
http://www.mygrid.org.uk/dev/issues/browse/T2-291
You will notice in Taverna 2 that although other processors depending
on the failing error will 'run' - they will not actually run for the
iterations involving the failure from above. A new transient error
will be produced from these processors that simply refer to the input
error (s) - as the service could not be invoked when one or more of
its input was an error or a list containing an error.
In theory your workflow should finish quite quickly if there's an
error at an early stage, you might see some iterations over the errors
still happening, but if the error is affecting every iterations you
would not invoke any more services.
In the Taverna 2 result view you can expand the errors to trace back
to from which processor the errors 'really' occurred in.
The difference of how Taverna 2 deals with these errors is that if
just one of 10 iterations failed (say because a gene ID was not found
in a database), the workflow would still run for the other 9 outputs
from the processor that gave a failure. In Taverna 1 nothing depending
on that processor would run.
If you don't prefer this behaviour (there's no point in processing the
other items if there's a single failure), you can force a failure for
the whole list by for instance inserting an Echo list in between, echo
list would consume a list at depth 1, and so would fail if there's
just a single item that is a failure. To 'block' on higher depth lists
you can Configure the echo list and increase the depth of it's input
and output port.
Parallel paths that don't depend directly or indirectly on data from
the failing processor would still run in both Taverna 1 and 2.
Also note that adding a coordination link is slightly different in
Taverna 2. As Taverna 1 processors with a failure don't complete, a
coordination to a failing processor would mean to not run if there was
a failure. Due to the pipelining model of Taverna 2 this behaviour is
slightly different, the iteration itself will complete, even if one or
more of those gave a failure. The coordination (or "Run after" as it's
called in 2.1 beta 2) is activated when the iteration has completed,
with or without failures.
Note that this feature (used with Fail_if_false and Fail_if_true) was
occasionally used as a kind of hack in Taverna 1 workflows to
implement a form of if/else branching, but often with unintended
execution of both branches (if you send 'somethingelse' both
fail_if_true and fail_if_false would complete!). A proper support for
branching is planned for Taverna 2, using a similar technique as the
looping support.
Apologies for the long explanation - but for your workflow - what kind
of failures do you get (part of an iteration?) - and how does the
workflow not currently 'stop'?
--
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
<?xml version="1.0" encoding="UTF-8"?>
<s:scufl xmlns:s="http://org.embl.ebi.escience/xscufl/0.1alpha"; version="0.2" log="0">
<s:workflowdescription lsid="urn:lsid:net.sf.taverna:wfDefinition:a055c39a-fbc1-4f83-a974-cce353aae0f0" author="" title="criticaltest" />
<s:processor name="always_fail">
<s:defaults>
<s:default name="bar">jyhj</s:default>
</s:defaults>
<s:local critical="true">org.embl.ebi.escience.scuflworkers.java.TestAlwaysFailingProcessor</s:local>
</s:processor>
<s:processor name="Echo_list">
<s:local>org.embl.ebi.escience.scuflworkers.java.EchoList</s:local>
</s:processor>
<s:processor name="Echo_list1">
<s:local>org.embl.ebi.escience.scuflworkers.java.EchoList</s:local>
</s:processor>
<s:processor name="Create_lots_of_strings">
<s:local>org.embl.ebi.escience.scuflworkers.java.EmitLotsOfStrings</s:local>
</s:processor>
<s:processor name="Echo_list2">
<s:local>org.embl.ebi.escience.scuflworkers.java.EchoList</s:local>
</s:processor>
<s:processor name="Echo_list3">
<s:local>org.embl.ebi.escience.scuflworkers.java.EchoList</s:local>
</s:processor>
<s:processor name="sleepy_echo">
<s:beanshell>
<s:scriptvalue>Thread.sleep(500);
out = in;</s:scriptvalue>
<s:beanshellinputlist>
<s:beanshellinput s:syntactictype="'text/plain'">out</s:beanshellinput>
</s:beanshellinputlist>
<s:beanshelloutputlist>
<s:beanshelloutput s:syntactictype="'text/plain'">in</s:beanshelloutput>
</s:beanshelloutputlist>
<s:dependencies s:classloader="iteration" />
</s:beanshell>
</s:processor>
<s:link source="Create_lots_of_strings:strings" sink="Echo_list:inputlist" />
<s:link source="Echo_list1:outputlist" sink="kujkj" />
<s:link source="Echo_list2:outputlist" sink="sleepy_echo:out" />
<s:link source="Echo_list3:outputlist" sink="kjkjkj" />
<s:link source="Echo_list:outputlist" sink="Echo_list2:inputlist" />
<s:link source="Echo_list:outputlist" sink="always_fail:foo" />
<s:link source="always_fail:urgle" sink="Echo_list3:inputlist" />
<s:link source="sleepy_echo:in" sink="Echo_list1:inputlist" />
<s:link source="Echo_list:outputlist" sink="jhjh" />
<s:sink name="jhjh" />
<s:sink name="kjkjkj" />
<s:sink name="kujkj" />
</s:scufl>
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
taverna-users mailing list
[email protected]
[email protected]
Web site: http://www.taverna.org.uk
Mailing lists: http://www.taverna.org.uk/taverna-mailing-lists/
