oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <chris.a.mattm...@jpl.nasa.gov>
Subject Re: Three Workflow questions
Date Fri, 02 Mar 2012 18:46:38 GMT
Hey Bruce,

Well right now there is some standardization in that our science algorithm
wrapper tries to both detect error codes and to use Workflow or Task specific
context metadata information to determine if the algorithm set a failure flag.
Your specifics below are similar too since you always can get the error log
or error message from the integrated algorithm and yes it does speed up
debugging.

Now, to go back to the other discussion. Can you please respond to my 
invite email to the OODT community? Emails like the below are plenty 
enough credit (not that you need any more) and reason for you to accept
the invite and keep hanging around the community. :)

Thanks,
Chris

On Mar 2, 2012, at 6:50 AM, Bruce Barkstrom wrote:

> As a generic question, has there been any standardization of
> using exceptions to identify where something happened?
> I have been coding so that every procedure has a Boolean
> variable named 'OK' and a variable length string named 'Err_Msg'.
> The string is built so that it identifies the procedure and the
> last good location in the procedure.  That really speeds up
> debugging.
> 
> Bruce B.
> 
> On Thu, Mar 1, 2012 at 10:59 PM, Mattmann, Chris A (388J)
> <chris.a.mattmann@jpl.nasa.gov> wrote:
>> Hi Keith,
>> 
>> Thanks for your questions! Happy to answer them below:
>> 
>> On Mar 1, 2012, at 9:54 AM, Keith Cummings wrote:
>> 
>>> Hi Chris,
>>> I have a few questions that I hope won't take you but a minute or two to
>>> answer.  If you prefer I send such questions to the OODT email list just
>>> let me know.
>>> 
>>> 1. The example code with the Workflow Manager shows examples of
>>> pre-conditions to tasks.  How do you configure post-conditions to tasks?
>> 
>> In the new wengine-style XML workflow documents, available in
>> trunk with the PackagedWorkflowRepository that came with OODT-70 [1],
>> you specify them with something like this:
>> 
>>                <conditions execution="parallel" type="pre">
>>                        <condition id-ref="urn:npp:MOA_IASI_L1C_Daily"/>
>>                        <condition id-ref="urn:npp:MOA_MHS_L1B_Daily"/>
>>                        <condition id-ref="urn:npp:MOA_AMSUA_L1B_Daily"/>
>>                </conditions>
>> 
>> Note that the conditions tag block can have an attribute 'type',
>> that you can set to post or to pre. At the moment, it simply reads
>> this, but as soon as the wengine is fully integrated, it will support
>> pre or post execution of these conditions. That should ship with 0.4.
>> 
>>> 
>>> 2. Is it possible to branch a workflow?  If so, can you point me to an
>>> example?
>> 
>> Sure, it's possible even in the 0.1-incubating, 0.2 and 0.3 versions.
>> The way that you branch a workflow is to:
>> 
>> 1. add a simple WorkflowTaskInstance implementation, whose goal
>> is to send an Event *back* to the same workflow manager, to kick off
>> another workflow. You can find a simple example of such a redirector
>> here [2].
>> 
>> 2. wire up an event for the next stage of the branch to kick off the
>> branch workflow. So, if you had a simple workflow:
>> 
>>      ----> t2---->t4
>> t1-/
>>     \
>>      ---->t3
>> 
>> You could support this with the following:
>> 
>> w1: t1, branch redirector (seeded with e2,e3)
>> w2: t2, t4
>> w3: t3
>> 
>> e1: w1
>> e2: w2
>> e3: w3
>> 
>> Where w=workflow, e=event, t=task
>> 
>> That make sense? If you need to fan in, you can support
>> this with a precondition on the incoming fan task, holding until
>> the other tasks in the workflow have finished, and then going.
>> 
>>> 
>>> 3. How do you interrupt a workflow from within?  Externally, you can
>>> just issue a stop command on the command-line for this workflow.  If a
>>> task (in the Java code) found that an error condition occurred, how
>>> could that be communicated back to the workflow manager?  (I found that
>>> throwing an Exception does the trick, but I was wondering if there was a
>>> less obtrusive way to signal the workflow to stop.)
>> 
>> You can, inside of a WorkflowTaskInstance, do something like:
>> 
>> XmlRpcWorfklowManager wm = new XmlRpcWorkflowManager(new URL(met.getMetadata("WorkflowUrl"));
>> wm.stopWorkflowInstance(met.getMetadata("WorkflowInstId"));
>> 
>> That will basically have the same effect as the external stop. Exceptions work fine
too,
>> even if they don't look elegant :)  Would be nice to have a WorkflowStoppedException,
which extends
>> some generic WorkflowTaskInstanceException, but for now, a good ol' Exception will
do it itoo.
>> 
>> HTH!
>> 
>> Cheers,
>> Chris
>> 
>> [1] https://issues.apache.org/jira/browse/OODT-70
>> [2] http://s.apache.org/NeK
>> 
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Chris Mattmann, Ph.D.
>> Senior Computer Scientist
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 171-266B, Mailstop: 171-246
>> Email: chris.a.mattmann@nasa.gov
>> WWW:   http://sunset.usc.edu/~mattmann/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Adjunct Assistant Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
Phone: +1 (818) 354-8810
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Mime
View raw message