Thanks Stian for the explanation, it helps. The error was raised, apparently, due to a service timeout. That service was a task taking about 5 minutes and somehow Tomcat complained. That JAXWS service called an external analysis tool to do something of our interest. I used Soaplab2 to wrap tools that take even longer time to run without any problem. I donot know why the JAXWS implementation of the same service fails. Any hint?
Thanks. Fan -----Original Message----- From: Stian Soiland-Reyes [mailto:[email protected]] Sent: July 15, 2009 5:06 AM To: [email protected] Subject: Re: [Taverna-users] detecting the errors in a workflow 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 Checked by AVG - www.avg.com Version: 8.5.387 / Virus Database: 270.13.14/2238 - Release Date: 07/14/09 18:03:00 ------------------------------------------------------------------------------ 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/
