Creating Objects to Gather Performance Data
After a Listener object is instantiated, the application begins to automatically record various system information, such as processor load, disk and network I/O, and communications from connected Managers. The application displays its performance data by using four different categories:
- Events
- Event objects are either created at the top level of the Listener
or logically grouped as subordinates in a Container object by
using either the lookupEvent constructor
or the
newoperator. In addition, sub-Events can be created under an Event. For more information about creating Event objects and recording Events, see Recording Events. - Accumulators
- Accumulator objects are always created as subordinates of Events by using the lookupAccumulator constructor.
- Meters
- Meter objects are either created at the top level of the Listener
or logically grouped as subordinates in a Container object by using
either the lookupMeter constructor
or the
newoperator.
In addition to these objects, Custom Messages are created at the top level of the Listener and are communicated the moment that recordCustomMessage is called.
Event and Meter objects can either be created at the top level
of the Listener or logically grouped as subordinates in a Container object (which is always created
at the top level of the Listener by using the lookupContainer constructor).
They can be created by using the lookupEvent or lookupMeter constructors or through the new
operator. Accumulator objects are always created as subordinates
of Events by using the lookupAccumulator constructor.
Custom Messages are always created at the top level of the Listener by
using the recordCustomMessage constructor.
The lookupObjectType member
functions creates the appropriate object only when that object does
not exist. If the object exists, the existing object is returned.
In addition, the application does not call delete on any objects that
are returned by these functions.
Naming and Locating Objects in the Listener
The
application creates each of these object types by specifying a unique
name for the object, which is assumed to be related to a concept or
operation in the application, such as a counter for "Documents Created".
Through overloaded member functions, the name can be specified either
as a UTF-8 or Unicode string (internally translated to UTF-8). The
names for any of these objects consist of any sequence of printable characters, excluding
the newline character. In addition, an internal copy for each string
is made, and the application does not need to maintain the pointer
after the lookupObjectType constructor returns.
After an object's creation, a pointer to the underlying
object is available for the lifetime of the Listener. Internally,
hash tables are used to map the unique names that are specified at
object creation time to the actual created objects. By calling the lookupObjectType constructor
and passing the same arguments as when an object was created, the
application obtains a pointer to the specified object whenever necessary.
Therefore, the application does not maintain a separate lookup table.
However, the application does retain a copy of the returned pointers
and reuse them to reduce the processing performance of the lookup
operation. Depending on the structure of the application, this task
might be accomplished by using global variables or by adding new member
variables to objects associated with operations within the application.