Page tree
Skip to end of metadata
Go to start of metadata

In coordinator/workers setup one can create workers manually. However, it is more convenient to have them created automatically, according to some definition. The WorkersCreationTaskHandler does just that. Here's a short description how to configure it.

An example

<task oid="0ce0ce48-ff0b-48db-aefe-a3adec0ed25b"
      xmlns="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:xsd="http://www.w3.org/2001/XMLSchema"
      xmlns:noop="http://midpoint.evolveum.com/xml/ns/public/task/noop/handler-3">
    <!-- Simulates importing 1000 accounts divided into 20 buckets. Processing of each account takes 1 second.
         Execution is carried out by 4 workers per node. -->
    <name>Multinode import simulation</name>
    <extension>
        <!-- 1 second per object -->
        <noop:delay xsi:type="xsd:int">1000</noop:delay>
        <noop:steps xsi:type="xsd:int">1</noop:steps>
    </extension>
    <ownerRef oid="00000000-0000-0000-0000-000000000002"/>
    <executionStatus>runnable</executionStatus>
    <category>Demo</category>
    <handlerUri>http://midpoint.evolveum.com/xml/ns/public/task/workers-creation/handler-3</handlerUri>
    <workManagement>
        <taskKind>coordinator</taskKind>
        <buckets>
            <numericSegmentation>
                <to>1000</to>
                <numberOfBuckets>20</numberOfBuckets>
            </numericSegmentation>
        </buckets>
        <workers>
            <handlerUri>http://midpoint.evolveum.com/xml/ns/public/task/noop/handler-3</handlerUri>
            <workersPerNode>
                <count>4</count>
            </workersPerNode>
        </workers>
    </workManagement>
    <recurrence>recurring</recurrence>
    <binding>loose</binding>
    <schedule>
        <interval>600</interval>
    </schedule>
</task>

The workManagement section defines here two important things:

  1. Segmentation of work into buckets:
    1. We create 20 buckets, each having 50 items. (So the first one is 0..49, then 50..99, 100..149, up to 950..999.)
  2. What workers are used to process the work:
    1. There will be four workers on each cluster node.
    2. Each worker will execute NoOpTaskHandler. (It does nothing in particular; just iterates through fictitious objects.)

Definition options

Here we describe workers configuration section. (The buckets section is explained elsewhere.)

ItemDescriptionDefault value
taskName

How to derive names for worker tasks. It is possible to use substitution strings of {coordinatorTaskName}, {node} and {index} here. In coordinatorTaskName there is the name of the coordinator task, node is the node

identifier and index numbers workers created for particular node, starting at 1.

{coordinatorTaskName} ({node}:{index})
handlerUriWorker tasks handler URI.Might be known from the context; otherwise there is no default and the URI has to be specified.
otherDeltasOther deltas to be applied to newly created worker task.-
workersPerNodeConfiguration of how many and what workers to be created for given cluster node(s).Single worker per node.

Workers per node are configured using the following items:

ItemDescriptionDefault value
nodeIdentifier (multivalued)

Node identifier(s) for which we are going to generate the tasks.

All nodes currently defined in the repository.
countHow many workers to create for given node(s).1
taskName

How to derive names for the tasks.

taskName defined in the parent element
executionGroupExecution group for created workers. It is possible to use substitution strings here.{node} (i.e. the task will execute on the specified node only – assuming that the default setting for execution capabilities is present)
otherDeltasOther deltas to be applied to newly created worker task in this group. Applied in addition to the deltas defined in parent element.-
  • No labels