Difference between revisions of "ExecutionPlan Configuration"
(→Queue Mechanism) |
|||
| (4 intermediate revisions by 3 users not shown) | |||
| Line 10: | Line 10: | ||
=Action elements restriction= | =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 | + | 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 restrictions 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: |
*[[ExecutionPlan_Elements#Boundary | Execution Boundary Element]] | *[[ExecutionPlan_Elements#Boundary | Execution Boundary Element]] | ||
*[[ExecutionPlan_Elements#Shell_Script | Shell script Element]] | *[[ExecutionPlan_Elements#Shell_Script | Shell script Element]] | ||
| Line 18: | Line 18: | ||
=Event Choking= | =Event Choking= | ||
| − | + | While a plan is being executed, a number of progress reporting events are emitted by the [[ExecutionPlan_Elements | 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 | *Progress reporting events | ||
*Performance reporting events | *Performance reporting events | ||
| + | |||
| + | =Queue Mechanism= | ||
| + | In order to support plan throttling, a [https://gcube.wiki.gcube-system.org/gcube/index.php/Execution_Engine#Queuing_Mechanism Queuing Mechanism] has been implemented. The following attributes support this cause: | ||
| + | *Utilization | ||
| + | *PassedBy | ||
=XML definition= | =XML definition= | ||
| Line 26: | Line 31: | ||
<config> | <config> | ||
<concurrentActionsPerBoundary value="10"/> | <concurrentActionsPerBoundary value="10"/> | ||
| + | <utilization value="1.0"/> | ||
| + | <passedBy value="0"/> | ||
<restrictTypes> | <restrictTypes> | ||
<restrict name="WS"/> | <restrict name="WS"/> | ||
Latest revision as of 16:45, 25 November 2013
Contents
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 restrictions 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:
- Utilization
- 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>
