The SLEE specification defines the operational lifecycle of a SLEE — illustrated, defined and summarised below.
SLEE lifecycle states
The SLEE lifecycle states are:
The node has been configured and initialised, and is ready to be started. Active resource adaptor entities on the node have been loaded and initialised, and SBBs on the node corresponding to active services have been loaded and are ready to be instantiated. (The entire event-driven subsystem, however, is idle: resource adaptor entities and the SLEE are not actively producing events, the event router is not processing work, and the SLEE is not creating SBB entities.
Resource adaptor entities on the node that have been recorded in the management database as being in the ACTIVE state are activated. The SLEE still does not create SBB entities. (The node transitions from this state to the RUNNING state when all startup tasks are complete, or to the STOPPING state when a startup task fails.)
Activated resource adaptor entities on the node can fire events, and the SLEE creates SBB entities and delivers events to them as needed.
Identical to the RUNNING state, except resource adaptor entities do not create (and the SLEE does not accept) new activity objects. Existing activity objects can end (according to the resource adaptor specification). The node transitions out of this state, returning to the STOPPED state, when all SLEE activities have ended. The node can transition to this state directly from the STARTING state, effective immediately, if it has no activity objects.
Independent cluster node states
Each event-router node in a Rhino cluster maintains its own SLEE-lifecycle state machine, independent of other nodes in the cluster. For example:
one node in a cluster might be in the STOPPED state
while another node is in the RUNNING state
while yet a third node is in the STOPPING state.
The operational state of each cluster node persists to the disk-based database.
Nodes STOPPED depending on persistent state and startup options
After completing bootup and initialisation, a node will enter the STOPPED state if:
the database has has no persistent operational state information for that node
the node's persistent operational state is STOPPED; or
the node was started with the -x option (see 3.1 Start Rhino in the Rhino Getting Started Guide).
Changing a node's operational state
You can change the operational state of any node at any time, as long as least one node in the cluster is available to perform the management operation (regardless of whether or not the node whose operational state being changed is a current cluster member). For example, you might set the operational state of node 103 to RUNNING before node 103 is started — then, when started, after it completes initialising, node 103 will enter the RUNNING state.
Changing a quorum node's operational state You can also change the operational state of a node which is a current member of the cluster as a quorum node.... but quorum nodes make no use of operational state information stored in the database, and will not respond to operational state changes. (A node only uses operational state information if it starts as a regular event-router node.)