The fetchResultLogLimit Property and Its Use

Technote (FAQ)


Is there a use for the fetchResultLogLimit property and is it possible to generate critical debug information for troubleshooting performance, stability, and runtime issues?


In V6 the mxe.db.fetchResultLogLimit property can be found in the path:
<application source root>/applications/maximo/properties/
The default value for this property is 200.

In V7 the fetchResultLogLimit property can be found in the system properties application
The default value for this property is 200

When enabled, this property generates a forced exception in the log each time the specified number of objects is loaded into a single set. The resulting stack trace shows what process is loading the objects.

When too many objects are being loaded and not released, this property can show how often a given process is loading the threshold count of objects. When set to 200, this will generate a stack trace when 200, 400, 600…etc objects are loaded into any single set.

Objects are organized in sets. You may have 20 sets and some sets will have 5 objects while other sets have 100 objects. The fetchResultLogLimit monitors objects in any single set. This property will not generate any output if the threshold set by the fetchResultLogLimit is not met. This means that setting the value to a higher number may not provide the necessary results to diagnose a problem. For example, setting the threshold to 1000 will cause an exception only when 1000 objects are in any one set so if there are 11 sets and each has 999 objects 10,989 objects will be in memory but no exception will be generated because none of the sets have 1000 or more objects in them. When troubleshooting memory problems, this threshold should be set no higher than 200 to show what is loading objects in a given set.

When the mboCount property is set on, once per minute, the total MBOs in memory are shown in the log in a similar format to the following:

15 Oct 2009 09:15:59:182 [INFO] [server10] [] MAXLABELS: mbosets (40), mbos (12200)

In this example, there are 40 MBO sets and the total of all MBOs in all sets is 12,200.

Typical fetchResultLogLimit output to the logs might look as follows when the threshold number is met:

IBM has internal tools that can correlate and trend this information combined with the output of the mbocount property and the LogSQLTimeLimit to determine many causes of performance, stability, and runtime problems. Since mbocount runs every minute, IBM can gather an understanding of the health of the JVM over a period of time. Often IBM will request up to 24 hours of logs to determine trends in user loads, memory requirements and many other points of interest.

This property should be left running at all times since a problem can often not be foreseen or replicated. In order to troubleshoot or find root cause of many issues, the data from this property is required.

For more information on debug properties see the document Using debug properties to monitor and troubleshoot performance

Also see:

The document what is the mbocount property
The document what is the logSQLTimeLimit property

Cross reference information
Segment Product Component Platform Version Edition
Systems and Asset Management IBM Maximo Asset Management Essentials
Systems and Asset Management Tivoli Asset Management
Systems and Asset Management Tivoli Asset Management for IT
Systems and Asset Management Tivoli Asset Management for Service Providers
Systems and Asset Management Tivoli Change and Configuration Management Database
Systems and Asset Management Tivoli Service Automation Manager
Systems and Asset Management Tivoli Service Request Manager

Document information

More support for:

Maximo Asset Management
System Related

Software version:

6.0, 6.1, 6.2, 6.2.1, 6.2.2, 6.2.3, 6.2.4, 6.2.5, 6.2.6, 6.2.7, 6.2.8, 7.1, 7.1.1, 7.1.2, 7.2, 7.2.1, 7.5

Operating system(s):

AIX, HP-UX, Linux, Solaris, Windows

Reference #:


Modified date:


Translate my page

Content navigation