Skip navigation links
eBus
4.5.0

Package net.sf.eBusx.monitor

This package provides messages to monitor both the on-going state and transient events of an eBus application at the object-level.

See: Description

Package net.sf.eBusx.monitor Description

This package provides messages to monitor both the on-going state and transient events of an eBus application at the object-level.

An on-going state is one that persists over time. An example is a disconnected connection. This state continues until either re-established or explicitly closed by the application. A transient event occurs in an instant, with no on-going impact to the application. An example of a transient event would be the application catching exception from which it immediately recovers. This exception is reported as a transient event so administrators are aware of the problem.

Both on-going status and transient events are reported with a given action level. This action level informs administrators about the event severity. The need to report ActionLevel.POSSIBLE_ACTION, ActionLevel.ACTION_REQUIRED and ActionLevel.FATAL_ERROR events is obvious: there is a problem occurring which must be corrected. But there is debate about reporting ActionLevel.NO_ACTION, information-only events. One view is that an application may be considered to be operating correctly unless stated otherwise. The opposing view is that, "if it goes without saying, then it goes even better with saying it." By reporting "no action" events, it is an explicit statement of correct operation.

Making your application monitorable

The starting point is to report your application name, version, copyright, description and optional name/value attributes using Monitor.applicationInfo(String, String, String, String, net.sf.eBus.messages.EField). This method should be called once at system start although there is nothing to prevent the information from being modified.

Classes that you want to monitor should implement Monitorable interface. This interface contains a single method: Monitorable.instanceName(). The implemented version should return a unique name for each class instance. This allows administrators to determine which instance is reporting a problem. The monitorable object must next be registered. The initial monitorable state is:

Monitor reports object registration via the MonitorUpdate notification message which contains the MonitorId and MonitorUpdate.updateFlag set to true.

Once registered, a monitorable object may update its on-going, persistent state and report transient events. If a registered monitorable object is to be discarded prior to application termination, it should be deregistered because the monitor subsystem maintains a reference to the monitorable object, preventing its garbage collection. Again, a MonitorUpdate notification is published with the updateFlag set to false to inform subscribers that the object is no longer available for monitoring.

Monitoring eBus applications

The steps involved in monitoring eBus applications are:
  1. Open a connection to each of the eBus applications you will be monitoring.
  2. Subscribe to the MonitorUpdate using the subject Monitor.MONITOR_UPDATE_SUBJECT.
  3. Request the currently registered monitored objects with MonitoredObjectRequest using the subject Monitor.MONITOR_UPDATE_SUBJECT.
    Note: because you are subscribe to MonitorUpdate, which reports monitor object registrations and deregistrations as they happen, there is a possibility of overlapping monitor identifiers as reported in MonitoredObjectReply.
  4. Subscribe to the PersistentStatusMessage and/or TransientStatusMessage for those monitor identifiers in which you are interested using MonitorId.toString() as the notification subject.
An optional step is to subscribe to ApplicationInfo with the subject Monitor.MONITOR_UPDATE_SUBJECT. This will each application's name, version, copyright, description and optional name, value attributes.
Skip navigation links
eBus
4.5.0