6.15 Statistics

The XMA-Runtime measures important events and handles the measurements over to an optional monitoring plugin. Measurements are made for variables which are defined below. A variable might for example the execution of an RPC. Each occurrence is reported together with its duration.

If no monitoring plugin is configured, XMA still works correctly, but of course all measurements are lost. To record the measurements, you have to implement the interface IMonitoring and configure your implementation as plugin in xma-app.xml.

An example for a configuration in the xma-app.xml would be:

<plugin-impl implements="at.spardat.xma.monitoring.IMonitoring"
 implServer="org.openxma.examples.YourMonitoringPlugin"/>
Note: In sIT Solutions the proprietary implementation ImcMonitor (at.spardat.xma.enterprise.MonitoringPlugin) is available for this purpose.

The following section describes the measured variables.

VariableMeaning
...:app<x>:rpcClient

The time it takes to execute a RemoteCall from the XMA clients point of view. This is the sum of what rpcServerEnter indicates plus the time needed for HTTP-transport between XMA client and XMA server. The time to construct the GUI at the client is not included.

...:app<x>:rpcServerEnter

Every XMA-RPC is handled by a servlet in the application-server. This measurement is the utmost possible in the web-application. It is the sum of rpcServerMethod plus the time it takes the XMA-Runtime to dispatch the request to the respective method. Not included is the time the application-server needs to dispatch the servlet-call (i.e., reading TCP-socket, putting request into the execute-queue).

...:app<x>:rpcServerMethod

Measures the time it takes to execute the server-side RPC-method written by the RPC-programmer, e.g., the method with the RemoteCall and RemoteReply -parameters.

Please note that the frequency of measurements of the rpc*-variables should be almost the same ( f ( rpcClient ) = f ( rpcServerEnter ) = f ( rpcServerMethod )). The durations are related as follows: d ( rpcClient ) >= d ( rpcServerEnter ) >= d ( rpcServerMethod ).

...:app<x>:tabular

Measures how long it takes the XMA server to serve a tabular table, see section How data sources work(Data Sources). The frequency of measurements of this variable is the sum of the frequencies of tabularLoaded and tabularNotModified . That means: A successful load operation either transfers a table to the client or results in an HTTP-NotModified response. If the first is the case, tabularLoaded is also measured, in the second case tabularNotModified is used. Formally: f ( tabular ) = f ( tabularLoaded ) + f ( tabularNotModified ).

...:app<x>:tabularLoaded

Is measured if a tabular table has been transferred to the client. Either tabularLoaded or tabularNotModified is measured.

...:app<x>:tabularNotModified

Measures how long it takes the server to detect that the table has not been modified. In this case, no tabular data is transferred to the client, but a HTTP-NotModified-Code instead. Either tabularLoaded or tabularNotModified is measured.

Table 6.13. monitor variables


If the XMA Runtime property at.spardat.xma.rpcDetailStatistics is set to true then the runtime gathers additional statistics specifically per RPC name. Use that option with care as it results in some overhead.


There is the possibility to access the end-to-end measurements at the server side. The method RemoteCall.getLastClientMeasurement() returns the client side measurement of the previous RPC. If called in the first RPC of a session, it will return null because there is no previous RPC in that case. The measurement contains the end-to-end duration as reported in the statistics variable rpcClient and the information if it was successfully or not. If you set the property xma.runtime.rpcMessureSize the measurement will contain the size of the transferred data, too.

If a plugin is configured then it is also possible to measure your own event durations and values. At the server side this is done by using the class TimeingEvent. A simple example for its usage when measuring durations of events:

 TimeingEvent event = new TimeingEvent("myvariable"); //begin event
 try {
    //do something
    event.success(); //end event, record success
 } finally {
      event.failure(); //end event, record failure: only the first call to an event is recorded
 }
Only the first call to an event should be recorded by the plugin. So you can use the finally block to record a failure, i.e. the occurrence of an Exception, without having to do explicit exception handling. Alternatively to duration measurement the value of a variable can be set directly by the static methods: TimeingEvent.success (String variable, int value), TimeingEvent.failure (String variable, int value).

At the client side the event measurement is done by an own class ClientTimingEvent, its usage does not have to be configured.Timing events reported by this class are transmitted to the server side (with the next RPC after event completion). At the server side the events are handed to the server side monitoring plugin as it is configured in the xma-app.xml. The usage is similar to the server side measurement:

 ClientTimingEvent event = new ClientTimingEvent("myvariable"); //begin event
 try {
    //do something
    event.success(); //end event, record success
 } finally {
      event.failure(); //end event, record failure: only the first call to an event is recorded
 }

Alternatively to duration measurement the value of a variable can be set directly by the static methods: ClientTimingEvent.success (String variable, int value), ClientTimingEvent.failure (String variable, int value).