This section covers general administrative tasks for day-to-day management of the Rhino SLEE, its components and entities deployed in it.
Rhino SLEE uses Java Management Extension (JMX) MBeans for management functionality. This includes both functions defined in the JAIN SLEE 1.1 specification and Rhino extensions that allow additional functionality, beyond what’s in the specification.
Rhino’s command-line console is a front end for these MBeans, providing access to functions for managing the following:
Management may also be performed via the Rhino Element Manager web interface.
From Rhino 3.0.0, state management commands and JMX methods for setting SLEE, Resource Adaptor Entity or Service state that do not take arguments accept a state change if at least one node in the cluster will change state.
These commands delete any per-node state and set the default desired state to the target state.
This behaviour is similar to enabling symmetric activation state mode for the component being updated in versions of Rhino prior to 3.0.0.
Cluster nodes that are already in the required desired state are ignored, those that need to change transition.
This behaviour is like the "-ifneeded" flag but the operation fails if no nodes are in the prerequisite state to transition to the target state.
The with-node-arg variants create/update (as necessary) per-node state for the requested nodes. All specified nodes must be in the required prerequisite state to transition to the target state.
It affects the start/stop/activate/deactivate/wait-til rhino-console and Ant tasks.
|The pool clustering mode is a feature introduced into Rhino in version 3.2. When using this mode of operation, deployment, management, and configuration state is not replicated between individual cluster nodes as happens when using the pre-existing Savanna clustering mode. To avoid confusion, almost all with-node-arg variants of management commands and JMX methods restrict the node (or node array) argument such that only the node the management operation is being performed on may be specified. This avoids situations such as executing the operation on node 101 to set the per-node SLEE state for node 102, but the operation not having any effect because node 101 does not replicate the change to other pool cluster nodes.|