ExecutionPlan Configuration

From Gcube Wiki
Revision as of 12:32, 9 October 2013 by John.gerbesiotis (Talk | contribs)

Jump to: navigation, search

Overview

Every plan is potentially one execution unit for the ExecutionEngine. Each plan while executing can request different parametrization which will affect the way it is executed. This parametrization is performed through the execution plan configuration element which is defined internally in each plan. The attributes that can be set for a plan are listed below.

Connection mode

During the execution of a plan the execution may be moved to a number of execution hosts (boundaries). This can create an arbitrarily big connection tree as the plan desires it. All these execution boundaries are connected in pairs. The type of connection can be configure to one of the two:

  • KeepAlive
    In this case the connection is made and is kept open until the completion of the execution of the connected boundary. Since this connection is only used to pass execution data in the beginning of the connection and then the results of the execution when the boundary is about to complete, in the meantime the connection remains idle. Control data are not send through this channel but through a different one.
  • Callback
    In this case the connection is made, the party that initialized the connection sends the execution details nad the connection is then closed. The accepting party then when it is ready to send back the execution results connects back to a specific callback address the caller supplied to report the results. A timeout can also be set when using this connection mode after which the connection is considered inactive and the initiating party stops waiting for results from the listener.

Action elements restriction

There is the possibility to enforce restriction to the number of elements that can be simultaneously running in the context of the same plan within an execution container (boundary). These restriction apply only to a single container and are not accumulated over all the running containers. The elements that can be restricted are statically defined and are:

In the context of the configuration of a plan any subset or all of the above can be defined to be included in the restriction list. The number of maximum concurrently running such elements is also defined in the same configuration.

Event Choking

While a plan is being executed, a number of progress reporting events are emitted by the Plan Elements, by default. The client may, for any reason, not want to be informed of such events. There is the option of disabling these events through the plan configuration class. The two types of events that can be choked by the execution engine are:

  • Progress reporting events
  • Performance reporting events

Queue Mechanism

In order to support plan throttling, a Queuing Mechanism has been implemented. The following attributes support this cause:

  • Utiliaztion
  • PassedBy

XML definition

<config>
  <concurrentActionsPerBoundary value="10"/>
  <utilization value="1.0"/>
  <passedBy value="0"/>
  <restrictTypes>
    <restrict name="WS"/>
    <restrict name="Boundary"/>
    ...
  </restrictTypes>
  <connectionMode value="Callback"/>
  <chokeProgressReporting value="false"/>
  <chokePerformanceReporting value="false"/>
</config>