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 new operator. 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 new operator.

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.