Any entity can use the standard “service-up” and “service-state” sensors to inform other entities and the GUI about its status.
In normal operation, entities should publish at least one “service not-up indicator”,
ServiceNotUpLogic.updateNotUpIndicator method. Each such indicator should have
a unique name or input sensor.
Attributes.SERVICE_UP will then be updated automatically
when there are no not-up indicators.
When there are transient problems that can be detected, to trigger
entity code can similarly set
ServiceProblemsLogic.updateProblemsIndicator with a unique namespace,
and subsequently clear it when the problem goes away.
These problems are reflected at runtime in the
allowing multiple problems to be tracked independently.
When an entity is changing the expected state, e.g. starting or stopping,
the expected state can be set using
this expected lifecycle state is considered together with
to compute the actual state. By default the logic in
ComputeServiceState is applied.
For common entities, good out-of-the-box logic is applied, as follows:
SoftwareProcessentities, lifecycle service state is updated by the framework and a service not-up indicator is linked to the driver
For common parents, including
AbstractGroupsubclasses (including clusters, fabrics, etc), the default enrichers analyse children and members to set a not-up indicator (requiring at least one child or member who is up) and a problem indicator (if any children or members are on-fire). In some cases other quorum checks are preferable; this can be set e.g. by overriding the
RUNNING_QUORUM_CHECK, as follows:
public static final ConfigKey<QuorumCheck> UP_QUORUM_CHECK = ConfigKeys.newConfigKeyWithDefault(AbstractGroup.UP_QUORUM_CHECK, "Require all children and members to be up for this node to be up", QuorumChecks.all());
initEnrichers()method can be overridden to specify a custom-configured enricher or set custom config key values (as done e.g. in
DynamicClusterImplso that zero children is permitted provided when the initial size is configured to be 0).
For sample code to set and more information on these methods’ behaviours,
see javadoc in
and tests in
Notes on Advanced Use
The enricher to derive
SERVICE_STATE_ACTUAL from the maps and expected state values discussed above
is added by the
This method can be overridden – or excluded altogether by by overriding
and can add enrichers created using the
suitably customized using methods on the returned spec object, for instance to look only at members
or specify a quorum function (from
If different logic is required for computing
noting that the first of these will replace the enricher added by the default
whereas the second one runs with a different namespace (unique tag).
For more information consult the javadoc on those classes.
Entities can set
Provided these entities never use the
the default enrichers will not override these values.