|
package
General Information
Monitoring Framework SPI's is used internally by the ORB to instrument
for JMX based Management and Monitoring. The
framework is very generic and easy to use and acts as facade to retrieve
the information from the running CORBA system.
This framework helps in building a nice Hierarchical Structure of Monitored
Objects that contains Monitored Attributes.
com.sun.corba.se.spi.orb.ORB has an API to get the RootMonitoredObject
and then User can traverse through the tree to
either instrument or retrieve the information for Monitoring.
Code Snippet to Instrument Connection Monitored Object
This example shows on how to instrument CorbaConnectionImpl 's attributes.
It exposes two
attributes, namely
1. Connection State
2. Response time statistics to Appeserver Admin Console or CLI
1. Instrumenting Connection State
/**
* Code Snippet to Instrument Connection Monitored Object
with
* ConnectionState Monitored Attribute. Steps to follow
*
* Step 1: Define a Monitored Attribute (ConnectionStateMonitoredAttribute)
Class by extending
*
StringMonitoredAttributeBase
*
* Step 2: Create Connection Manager Monitored Object and
add that to
*
Root Monitored Object.
*
* Step 3: Create Connection Monitored Object and
add it to Connection Manager Monitored Object
*
* Step 4: Instantiate Concrete Attribute (ConnectionStateMonitoredAttribute)
Class and add that to
*
the Connection MonitoredObject
*
* Step 5: Adds ConnectionMonitoredObject to ConnectionManagerMonitoredObject
*
*/
/**
* Step 1: Define a Monitored Attribute Class by extending
*
StringMonitoredAttributeBase
*/
/**
* ConnectionState gets the value on demand.
*/
#import com.sun.corba.se.spi.monitoring.LongMonitoredAttributeBase
#import com.sun.corba.se.spi.transport.CorbaConnection;
public class ConnectionStateMonitoredAttribute extends StringMonitoredAttributeBase
{
CorbaConnection connection;
public ConnectionInUseMonitoredAttribute( String
name, String desc,
CorbaConnection con )
{
super( name, desc );
connection = con;
}
public Object getValue( ) {
// Delegate the getValue
call to connection
// so, there is no state
maintained in this attribute object itself
// and also the locking
will be the responsibility of Connection
// Object. By doing this
we will avoid global locking and possibly
// avoiding the bottleneck
return connection.getState(
);
}
// IMPORTANT: In this case we don't have to implement
clearState() method
// If there is a need to implement this method like
for POACounter, the
// call again can be delegated to the Object which
maintains the real
// state. clearState() is invoked whenever there
is a call to CORBAMBean.startMonitoring()
}
/**
* Step 2: Create Connection Manager Monitored Object and
add that to
* Root
Monitored Object.
*/
import com.sun.corba.se.spi.monitoring.MonitoringFactories;
import com.sun.corba.se.spi.monitoring.MonitoredObject;
private static MonitoredObject connectionManagerMonitoredObject;
private static MonitoredObject connectionMonitoredObject;
private void instrumentConnectionManager( ) {
connectionManagerMonitoredObject
=
MonitoringFactories.getMonitoredObjectFactory().createMonitoredObject(
"ConnectionManagerMonitoredObject",
"Used to Monitor the stats on All IIOP Connections " );
orb.getRootMonitoredObject().addChild(connectionManagerMonitoredObject
);
}
/**
* Step 3: Create Connection Monitored Object and
add it to Connection Manager Monitored Object
*
* Step 4: Instantiate Concrete Attribute (ConnectionStateMonitoredAttribute)
Class and add that to
*
the Connection MonitoredObject
*
* Step 5: Add ConnectionMonitoredObject to ConnectionManagerMonitoredObject
*/
private void instrumentConnectionObject( CorbConnection connection
) {
// Step 3
MonitoredObject connectionMonitoredObject =
MonitoringFactories.getMonitoredObjectFactory().createMonitoredObject(
connection.getName(),
"Used to Monitor the stats on one connection" );
// Step 4
ConnectionStateMonitoredAttribute connectionState
=
new ConnectionStateMonitoredAttribute(
"Connection_State",
"Provides the state of the IIOP Connection ...", connection );
connectionMonitoredObject.addAttribute( connectionState
);
// Step 5
connectionManagerMonitoredObject.addChild( connectionMonitoredObject
);
}
Code Snippet to Instrument A Statistic Type Monitored
Attribute
/**
* Assuming ConnectionMonitoredObject is already added
to the MonitoredObject Hierarchy.
* This example code shows how to instrument ConnectionMonitoredObject
with a new
* StatisticMonitoredAttribute.
*
* IMPORTANT: StatisticsMonitoredAttribute
is mostly write mostly and read sparingly, i.e.,
* the frequency of writes(Collecting samples)
is high. It is the responsibility of user to synchronize
* the sample() method and the StatisticMonitoredAttribute
will synchronize clearState() and
* getValue() using the mutex object sent.
*/
private void instrumentStatsToConnectionObject( MonitoredObject connectionMonitoredObject
) {
// Step 4
StatisticsAccumulator connectRequestStatsAccumulator
=
// Microseconds is the unit
used for statistics measure
new StatisticsAccumulator(
"Micro Seconds" );
// Pass Name, Description, Statistic Accumulator
Instance, Mutex (The
// Object on which we need to synchronize for stats
sample collection)
StatisticMonitoredAttribute sm = new StatisticMonitoredAttribute(
connection.getName() + "Stats",
"Connection Request Stats",
connectRequestStatsAccumulator, this );
connectionMonitoredObject.addAttribute( sm );
// Now, The user can accumulate the samples by calling
into
// connectRequestStatsAccumulator.sample( <value>
);
// Finally When ASAdmin request for the value of
this Stats Monitored Attribute
// by using standard getValue() call. It will return
a formatted Stats Value like
// For Example
//
// Minimum Value = 200 Microseconds
// Maximum Value = 928 Microseconds
// Average Value = 523 Microseconds
// Standard Deviation = 53.72 Microseconds
// Sample Collected = 435
}
Caution On Global Locking (Synchronization):
It's important to make sure that collecting Stats and other state information
for monitoring doesn't impact performance. Please look at the following
don'ts
to understand better.
Do not add a special mutex for synchronizing MonitoredObject:
Let's take an example of exposing a counter that counts Requests on
this connection and 2 possible ways of doing this
1. Define Counter by extending LongMonitoredAttributeBase
public class Counter extends LongMonitoredAttributeBase
{
private long counter;
Counter( String name, String
desc ) {
super( name, desc );
}
public synchronized
void increment( ) {
counter++;
}
public synchronized
Object getValue( ) {
return new Long( counter );
}
}
2. Or Define a RequestCounter by extending LongMonitoredAttributeBase
again, but no special
synchronization is done
public class RequestCounter extends LongMonitoredAttributeBase
{
private CorbaConnection
connection;
RequestCounter( String name,
String desc, CorbaConnection con ) {
super( name, desc );
connection = con;
}
public Object getValue( )
{
return connection.getRequestCount( );
}
}
The problem with Alternative (1) is that there may
be unneccesary extra synchronization happening for every method and it
may become a bottle neck
particularly if this object is accessed quite
often. In Alternative (2), the synchronization happens only in the Connection
object and no special sync
is required in the RequestCounter object.
Important Thing To Know On StatisticMonitoredAttribute
type:
The clearState() and getValue() call will be synchronized using the
mutex passed by the external object, but sample() method in StatisticsAccumulator
is not synchronized. It is the responsibility of user to synchronize
to make sure that the samples collected (The mutex passed into the StatisticsAccumulator must be the one used to synchronize calls to sample() ).
@since JDK1.5 @serial exclude
|