Administration - JOnAS 5 Life Cycle


JOnAS 5 Life Cycle

Rationale

  • Enhance Server State Control
  • Provide more flexibility and dynamicity in services control

State control in JOnAS 4

  • Only two actions available for the administrator: start everything (JVM and services defined in jonas.properties), stop everything
  • A started service cannot be stopped individually
  • A service not started at server launch time cannot be started afterward
  • There is no JSR77 compliant state management: no state at J2EEServer MBean level. There is an had oc state management defined at the Adm object level, defining states NOT_READY,READY, STOPPED.

\ 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:

  • control JOnAS services lifecycle: be able to start/stop/restart a service, be aware of its state
  • base server state management on JSR77 State Management specification
  • define and implement correlation between services states and server state
  • provide consistency between state of a managed server within a Domain and the state of its ServerProxy as seen by the Master server

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:

  • STARTING:the server is considered as starting as soon as an administrator has launched a start command. Such a command aims at starting a set of services as defined by the jonas.services property in the jonas.properties file. Possible transitions from this state are
    • RUNNING (start successful)
    • FAILED (failure)
    • STOPPING, if the administrator has decided to stop the server.
  • RUNNING: the server has successfully started. See details below. Possible transitions are
    • FAILED (failure)
    • STOPPING if the administrator has decided to stop the server.
  • FAILED: one or several JOnAS services, considered as mandatory, are in a FAILED state. See details below. Possible transitions are
    • STARTING
    • STOPPING
  • STOPPING: the server is considered as stopping as soon as the administrator has launched an operation aiming at stopping all active services.
  • STOPPED: all services, except bootstrap ones (see below), are stopped. The server is manageable, some services can be started. Future goals aim at being able to configure a stopped server.

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.:

  • a non critical service could not be started (is in the FAILED state) due to some configuration issues
  • an applicative module of the autoload directory could not be loaded.

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

  • start
    • Total start of the server, i.e. JVM, OSGi framework, all services defined in jonas.properties. The server enters a STARTING state and goes into a RUNNING or FAILED state.
      • jonas start
    • Start only the platform, with possibility to afterward start one or several services through explicit administrator operations. The server reaches a STOPPED state. No JOnAS service started, except bootstrap services, to make the server manageable. Goal of bootstrap services is to make a jmx-remote connector available.
      • jonas start -option where -option is to be defined (-bootstrap, or -nop)
      • jonas bootstrap
    • (re)start a server which is in a STOPPED state. Start all services defined in jonas.properties.
      • jonas start
  • Stop
    • Stop all active services, going into STOPPING state, then into STOPPED or FAILED. Bootstrap services still running
      • jonas stop
    • Total stop, services and platform
      • jonas -option where -option is to be defined, e.g. -halt or
      • jonas halt
  • Reboot
    • equivalent to a jonas halt followed by a jonas bootstrap
      • jonas reboot
  • Status
    • To get the states of a server and of its services
      • jonas status
  • Admin
    • Legacy admin command
      • jonas admin

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:

  • RUNNING: the service is ready, OSGi bundle(s) have been started and are in the ACTIVE state, and are VALID from the IPOJO point of view
  • STOPPED: OSGi bundle(s) have been stopped. The corresponding MBean is still registered.
  • FAILED: OSGi bundle(s) have not been able to start (INVALID IPOJO state). If the reason is the dependence on a non started OSGi service, this information is available through IPOJO and can be provided to the administrator.

Management Operations

  • Installation (= bundle installation). Service is manageable
    • jonas install -service sv1
  • Un-installation (= bundle uninstall). Service is no more manageable.
    • jonas uninstall - service sv1
  • Services start
    • jonas start -service sv1[,sv2]
  • Services stop
    • jonas stop -service sv1[,sv2]
  • Service update
    • jonas update -service sv1
  • Service status
    • jonas status -service sv1

Implementation notes

Bootstrap Services

This is the minimal stuff allowing a server to exist from the management point of view. It should contain

  • a JMX agent (the JMX server of the JVM ?)
  • a jmx-remote connector (server part)
  • a registry in order to register the jmx-remote connector
  • some MBeans like the J2EEServer, J2EEDomain, JavaVM

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:

  • Felix jars + carol + endorsed configuration for Jacorb
  • Initial set of bundles:
    • Carol based registry service
    • JMX Service for connector registration
    • iPOJO (required by JMX and Carol services)
    • Config Admin