myGrid

  • Dashboards
  • Projects
  • Issues
  • Help
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What’s New
  • Log In
Scufl 2
  1. Scufl 2
  2. SCUFL2-126 Remove dispatch stack, configure proc...
  3. SCUFL2-131

JavaDoc on Processor detailing default config

  • Log In
  •  Views
    • XML
    • Word
    • Printable

Details

  • Type: Sub-task Sub-task
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
  • Commits
Hide
Permalink
Stian Soiland-Reyes added a comment - 2013-10-25 17:08

Added:

/**
 * A <code>Processor</code> is a {@link Workflow} component that controls the
 * invocation of activities.
 * <p>
 * When a <code>Workflow</code> is run, a particular {@link Activity} will be
 * specified as bound to the <code>Processor</code> by the {@link Profile}.
 * <p>
 * A <code>Processor</code> contains an {@link IterationStrategyStack} to
 * describe iterations, and may have {@link InputProcessorPort input} and
 * {@link OutputProcessorPort output} ports. The <code>Processor</code> can be
 * configured with a {@link Configuration} within a {@link Profile} to specify
 * execution details such as retries or parallel jobs.
 * <p>
 * The {@link #getType()} of a Processor is normally fixed to the value given by
 * {@value #PROCESSOR_TYPE}. The configuration of a processor should
 * correspondingly be of the type given by the constant {@value #CONFIG_TYPE}.
 * <p>
 * The default (implied) configuration of a Processor is as of Taverna 3.0 alpha
 * 2:
 * 
 * <pre>
 * { 
 *  "retry": {
 *     "maxRetries": 0,
 *     "initialDelay": 1000,
 *     "maxDelay": 5000,
 *     "backoffFactor": 1.0
 *  }, 
 *  "parallelize": {
 *      "maxJobs": 1
 *  }
 * </pre>
 * 
 * These defaults mean that the processor would not retry the operation, and
 * would only perform one concurrent invocation within a given workflow run.
 * <p>
 * You can provide a partial configuration, e.g. to activate 5 retries using the
 * default initialDelay, add a {@link Configuration} of this {@link Processor}
 * to the {@link Profile} with the keys:
 * 
 * <pre>
 * { 
 *   "retry": {
 *     "maxRetries": 5
 *   }
 * }
 * </pre>
 * <p>
 * Additionally, do..while-style looping can be configured using the key "loop":
 * 
 * <pre>
 * {
 *   "loop": {
 *     "comparePort": "outputB",
 *     "comparison": "EqualTo",
 *     "compareValue": "15",
 *     "delay": 0.5,
 *     "runFirst": true,
 *     "isFeedBack": false,
 *     "conditionActivity": "looping-loop"
 *   }
 * }
 * </pre>
 * <p>
 * Note that this is different from looping over incoming values, which happens
 * according to the {@link #getIterationStrategyStack()}..
 * </p>
 * The above loop configuration would repeat calling of the activity bound to
 * this processor until its output "outputB" is equal to the string value "15" -
 * with a delay of 0.5 seconds between each try.
 * <p>
 * if <code>"isFeedBack": true</code>, then outputs from the processor will on
 * repeated invocations replace the original input values where the port names
 * match. Note that the processor ports should be connected in the containing
 * workflow.
 * <p>
 * <code>"runFirst": true</code> means that the activity is called at least
 * once, which is generally needed to get a port value to compare.
 * <p>
 * The <code>"conditionActivity"</code> indicates the name of an
 * {@link Activity} within the {@link Profile}, here called "looping-loop". This
 * activity is invoked with the current processor output values as input ports,
 * and if its output port "loop" contains the string value "true", then the
 * processor is invoked again. If the condition output port matches a processor
 * input port, then the returned values are used instead of the original
 * processor inputs. The conditionActivity is then repeated on the new output
 * values, repeated until "loop" no longer is "true".
 * <p>
 * As of Taverna 3 alpha 2, the "conditionActivity" is called directly without
 * consideration of the other parameters. This typically contains a beanshell
 * script generated from the above parameters and performs the actual
 * comparisons.
 * <p>
 * FIXME: This conditionActivity currently has to be regenerated when the other
 * parameters have changed. This now happens within the Taverna 3 workbench user
 * interface when configuring looping. The ideal SCUFL2 behaviour would be to EITHER
 * provide a custom conditionActivity OR the parameters.
 * 
 * @author Alan R Williams
 * @author Stian Soiland-Reyes
 */
Show
Stian Soiland-Reyes added a comment - 2013-10-25 17:08 Added: /** * A <code>Processor</code> is a {@link Workflow} component that controls the * invocation of activities. * <p> * When a <code>Workflow</code> is run, a particular {@link Activity} will be * specified as bound to the <code>Processor</code> by the {@link Profile}. * <p> * A <code>Processor</code> contains an {@link IterationStrategyStack} to * describe iterations, and may have {@link InputProcessorPort input} and * {@link OutputProcessorPort output} ports. The <code>Processor</code> can be * configured with a {@link Configuration} within a {@link Profile} to specify * execution details such as retries or parallel jobs. * <p> * The {@link #getType()} of a Processor is normally fixed to the value given by * {@value #PROCESSOR_TYPE}. The configuration of a processor should * correspondingly be of the type given by the constant {@value #CONFIG_TYPE}. * <p> * The default (implied) configuration of a Processor is as of Taverna 3.0 alpha * 2: * * <pre> * { * "retry" : { * "maxRetries" : 0, * "initialDelay" : 1000, * "maxDelay" : 5000, * "backoffFactor" : 1.0 * }, * "parallelize" : { * "maxJobs" : 1 * } * </pre> * * These defaults mean that the processor would not retry the operation, and * would only perform one concurrent invocation within a given workflow run. * <p> * You can provide a partial configuration, e.g. to activate 5 retries using the * default initialDelay, add a {@link Configuration} of this {@link Processor} * to the {@link Profile} with the keys: * * <pre> * { * "retry" : { * "maxRetries" : 5 * } * } * </pre> * <p> * Additionally, do .. while -style looping can be configured using the key "loop" : * * <pre> * { * "loop" : { * "comparePort" : "outputB" , * "comparison" : "EqualTo" , * "compareValue" : "15" , * "delay" : 0.5, * "runFirst" : true , * "isFeedBack" : false , * "conditionActivity" : "looping-loop" * } * } * </pre> * <p> * Note that this is different from looping over incoming values, which happens * according to the {@link #getIterationStrategyStack()}.. * </p> * The above loop configuration would repeat calling of the activity bound to * this processor until its output "outputB" is equal to the string value "15" - * with a delay of 0.5 seconds between each try . * <p> * if <code> "isFeedBack" : true </code>, then outputs from the processor will on * repeated invocations replace the original input values where the port names * match. Note that the processor ports should be connected in the containing * workflow. * <p> * <code> "runFirst" : true </code> means that the activity is called at least * once, which is generally needed to get a port value to compare. * <p> * The <code> "conditionActivity" </code> indicates the name of an * {@link Activity} within the {@link Profile}, here called "looping-loop" . This * activity is invoked with the current processor output values as input ports, * and if its output port "loop" contains the string value " true " , then the * processor is invoked again. If the condition output port matches a processor * input port, then the returned values are used instead of the original * processor inputs. The conditionActivity is then repeated on the new output * values, repeated until "loop" no longer is " true " . * <p> * As of Taverna 3 alpha 2, the "conditionActivity" is called directly without * consideration of the other parameters. This typically contains a beanshell * script generated from the above parameters and performs the actual * comparisons. * <p> * FIXME: This conditionActivity currently has to be regenerated when the other * parameters have changed. This now happens within the Taverna 3 workbench user * interface when configuring looping. The ideal SCUFL2 behaviour would be to EITHER * provide a custom conditionActivity OR the parameters. * * @author Alan R Williams * @author Stian Soiland-Reyes */
Hide
Permalink
Jenkins Automated build added a comment - 2013-10-25 17:15

SUCCESS: Integrated in scufl2 #3989
SCUFL2-131 javadoc on default processor config (stian: c4e95d0ba2b3681d06e2707bb1bac1e769e05639)

  • scufl2-api/src/main/java/uk/org/taverna/scufl2/api/core/Processor.java
Show
Jenkins Automated build added a comment - 2013-10-25 17:15 SUCCESS: Integrated in scufl2 #3989 SCUFL2-131 javadoc on default processor config (stian: c4e95d0ba2b3681d06e2707bb1bac1e769e05639 ) scufl2-api/src/main/java/uk/org/taverna/scufl2/api/core/Processor.java

People

  • Assignee:
    Stian Soiland-Reyes
    Reporter:
    Stian Soiland-Reyes
  • Votes:
    0 Vote for this issue
    Watchers:
    0 Start watching this issue

Dates

  • Created:
    2013-10-23 11:28
    Updated:
    2013-10-25 17:15
    Resolved:
    2013-10-25 17:08

Time Tracking

Estimated:
Original Estimate - 1 hour
1h
Remaining:
Remaining Estimate - 1 hour
1h
Logged:
Time Spent - Not Specified
Not Specified
  • Atlassian JIRA (v6.1.2#6157-sha1:98c7292)
  • About JIRA
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for myGrid. Try JIRA - bug tracking software for your team.