JOnAS header

JOnAS 5 Life Cycle

Rationale

State control in JOnAS 4


Regarding State Management in a Domain, the Master server handles ServerProxy objects, representing managed servers belonging to the domain. Each ServerProxy contains a jmx-remote connection to the managed server. A ServerProxy can be in one of the following states: INITIAL, STARTING, RUNNING, STOPPING, STOPPED, UNREACHEABLE, FAILED. State transitions are based on events issued from the Discovery service or from the jmx-remote connection validity. There is no direct link between the state handled by the ServerProxy (so the state visible from the Master server) and the actual state handled by the managed server itself.

State Control in JOnAS 5

To achieve the two objectives, server state control enhancement, and services control flexibility, the following points must be addressed:

Server Lifecycle

Server State Management

The goal is to handle server state at the J2EEServer MBean, based on JSR77, and linked to Services state management. JSR77 states are the following:
Details about the RUNNING state
The server reaches this state when a set of services have well started (are in the RUNNING state). This set can be defined by the set of services initially defined in the jonas.properties file. Some of these services could be considered as non critical and could be excluded from this set: if such a non critical service does not reach the RUNNING state, the server by itself could still reach the RUNNING state, in some kind of degraded mode, information that should appear somewhere in the available management information. This is some kind of management facility that could be provided to the administrator, but the default behaviour will be that of today, i.e. all services of the predefined set must be running in order for the server to be running.
So a RUNNING state could be annotated with some information related to a degraded behaviour, e.g.: Transition from RUNNING to FAILED if a critical service goes to FAILED state.
Transition from RUNNING to STOPPING if the administrator launches a server stop operation. Stopping one or several services does not change the RUNNING state. To be defined the case where the administrator stops critical services, this case should be automatically detected and the server should go to the STOPPED state.
Details on the FAILED state
Default behaviour is to considere the server in a FAILED state if at least one of the started services is in the FAILED state. Optionnally, if one or several applications, considered as critical, were not able to start, the server may be considered in a FAILED state. So some means should be provided to define criteria to force the move of the server in a FAILED state (e.g. a critical application could not start), or to force the server to stay in the RUNNING state (e.g. a non critical services failed).

Management Operations


Note: This jonas command will temporarily be named j5 in order to co-exist with the jonas command associated to the non OSGi mode. j5 start/bootstrap/halt are scripts to start/stop OSGi platform. j5 stop/status/admin are Java/JMX clients connecting to the managed server through the jmx-remote connector.

Services Lifecycle

State Management

Preliminary question is to know which JOnAS services should be managed in a JOnAS 5 instance. Currently, all services defined in jonas.properties are addressed. However, it could be considered that not all services are present at JOnAS installation time (in the near future, "light" JOnAS installation may be considered for reducing server memory footprint, thus addressing embedded applications; this is what the OSGi architecture allows). In this case, a service not present at installation time can be installed afterward. This is possible relying on the OBR (OSGi registry). So configuration of a dynamically installed service should be possible. Moreover, the administrator could uninstall a service after having stopped it. So state of a service is dependent of the state of the bundle(s) where it is implemented. And such bundle(s) can also depend on other services. So the state of a service is also related to the states of the services it depends on.
It has been decided to map services state management to JSR77 (as done for server state).
INSTALLED state will not be explicitely exposed, however its definition, "the server is ready to start a service" is used for implementing the service installation command.
An installed service is manageable, i.e. a MBean is registered in the JMX server for this service. An uninstalled service is not manageable, there is no associated MBean (the MBean has not been created or has been unregistered).
Services states:

Management Operations

Implementation notes

Bootstrap Services

This is the minimal stuff allowing a server to exist from the management point of view. It should contain The jmx-remote is currently created by the JMX service and the registy is provided by CAROL. So the bootstrap services could be the JMX agent, with the JMX service and the CAROL service.

JOnAS Bootstrap details

Due to limitations in the CORBA API that do not allow dynamism (like interceptors pluggability, ...), the Carol and Jacorb jars have to be provided in the initial classpath (aka not provided from bundles), or from the endorsed directory.

So, initially, the "bootstrap" will be composed of:

Log-in Register
Copyright © ObjectWeb 2006
Creator: exertier  Date: 2007/11/19 12:41 Last Author: sauthieg  Date: 2007/11/26 09:55
Java, and all Java-based trademarks, JMX and all JMX based trademarks, are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. OSGi is a trademark, registered trademark, or service mark of The OSGi Alliance in the US and other countries. Bull is independent of Sun Microsystems, Inc.