The root resource for a Domain or Host Controller or an individual server will expose an operation named " ". This operation executes a list of other operations as an atomic unit (although the atomicity composite
requirement can be relaxed. The structure of the request for the "composite" operation has the same fundamental structure as a simple operation (i.e. operation name, address, params as key value pairs).
{ "operation" => "composite", "address" => [], "steps" => [ { "operation" => "write-attribute", "address" => [ ("profile" => "production"), ("subsystem" => "threads"), ("bounded-queue-thread-pool" => "pool1") ], "count" => "count", "value" => 20 }, { "operation" => "write-attribute", "address" => [ ("profile" => "production"), ("subsystem" => "threads"), ("bounded-queue-thread-pool" => "pool2") ], "name" => "count", "value" => 10 } ], "operation-headers" => { "rollback-on-runtime-failure => false } }
The "composite" operation takes a single parameter:
– a list, where each item in the list has the same structure as a simple operation request. In steps
the example above each of the two steps is modifying the thread pool configuration for a different pool. There need not be any particular relationship between the steps. Note that the
and operation headers are not supported for rollback-on-runtime-failure rollout-plan
the individual steps in a composite operation.
The rollback-on-runtime-failure operation header discussed above has a particular meaning when applied to a composite operation, controlling whether steps that successfully execute should be reverted if other steps fail at runtime. Note that if any steps modify the persistent configuration, and any of those steps fail, all steps will be reverted. Partial/incomplete changes to the persistent configuration are not allowed.
JBoss Community Documentation Page 193 of 660
Operations with a Rollout Plan
Operations targeted at domain or host level resources can potentially impact multiple servers. Such operations can include a "rollout plan" detailing the sequence in which the operation should be applied to servers as well as policies for detailing whether the operation should be reverted if it fails to execute successfully on some servers.
If the operation includes a rollout plan, the structure is as follows:
{ "operation" => "write-attribute", "address" => [ ("profile" => "production"), ("subsystem" => "threads"), ("bounded-queue-thread-pool" => "pool1") ], "name" => "count", "value" => 20, "operation-headers" => { "rollout-plan" => { "in-series" => [ { "concurrent-groups" => { "groupA" => { "rolling-to-servers" => true, "max-failure-percentage" => 20 }, "groupB" => undefined } }, { "server-group" => { "groupC" => { "rolling-to-servers" => false, "max-failed-servers" => 1 } } }, { "concurrent-groups" => { "groupD" => { "rolling-to-servers" => true, "max-failure-percentage" => 20 }, "groupE" => undefined } } ], "rollback-across-groups" => true } } }
As you can see, the rollout plan is another structure in the operation-headers section. The root node of the structure allows two children:
– a list – A list of activities that are to be performed in series, with each activity reaching in-series
completion before the next step is executed. Each activity involves the application of the operation to the servers in one or more server groups. See below for details on each element in the list.
– boolean – indicates whether the need to rollback the operation on all rollback-across-groups
the servers in one server group should trigger a rollback across all the server groups. This is an optional setting, and defaults to false.
Each element in the list under the in-series node must have one or the other of the following structures: – a map of server group names to policies controlling how the operation concurrent-groups
should be applied to that server group. For each server group in the map, the operation may be applied concurrently. See below for details on the per-server-group policy configuration.
– a single key/value mapping of a server group name to a policy controlling how the server-group
operation should be applied to that server group. See below for details on the policy configuration. (Note: there is no difference in plan execution between this and a "concurrent-groups" map with a single entry.)
The policy controlling how the operation is applied to the servers within a server group has the following elements, each of which is optional:
– boolean – If true, the operation will be applied to each server in the group rolling-to-servers
in series. If false or not specified, the operation will be applied to the servers in the group concurrently.
– int – Maximum number of servers in the group that can fail to apply the max-failed-servers
operation before it should be reverted on all servers in the group. The default value if not specified is zero; i.e. failure on any server triggers rollback across the group.
– int between 0 and 100 – Maximum percentage of the total number of max-failure-percentage
servers in the group that can fail to apply the operation before it should be reverted on all servers in the group. The default value if not specified is zero; i.e. failure on any server triggers rollback across the group.
If both max-failed-servers and max-failure-percentage are set, max-failure-percentage takes precedence.
Looking at the (contrived) example above, application of the operation to the servers in the domain would be done in 3 phases. If the policy for any server group triggers a rollback of the operation across the server group, all other server groups will be rolled back as well. The 3 phases are:
JBoss Community Documentation Page 195 of 660 1.
2.
3.
Server groups groupA and groupB will have the operation applied concurrently. The operation will be applied to the servers in groupA in series, while all servers in groupB will handle the operation concurrently. If more than 20% of the servers in groupA fail to apply the operation, it will be rolled back across that group. If any servers in groupB fail to apply the operation it will be rolled back across that group.
Once all servers in groupA and groupB are complete, the operation will be applied to the servers in groupC. Those servers will handle the operation concurrently. If more than one server in groupC fails to apply the operation it will be rolled back across that group.
Once all servers in groupC are complete, server groups groupD and groupE will have the operation applied concurrently. The operation will be applied to the servers in groupD in series, while all servers in groupE will handle the operation concurrently. If more than 20% of the servers in groupD fail to apply the operation, it will be rolled back across that group. If any servers in groupE fail to apply the operation it will be rolled back across that group.