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.
| Variable | Meaning |
| ...: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.
| Variable | Meaning |
...:app<x>:rpc< class.method > | Measures the time it takes to execute the named server-side RPC-method written by the RPC-programmer. There will be one such variable for each different RPC-method actually used in the application, containing the full qualified class name and method name. The sum of the frequencies of all these individual rpc-method-variables equals the frequency of rpcServerMethod. |
Table 6.14. monitor additional variables
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).