Troubleshooting on Notes and Expeditor
VanStaub 120000BGUR Visits (2781)
Often IBM support will request trace data to further investigate a problem. What is this data, how is it enabled, and how can it be used to pro-actively solve problems before contacting IBM? The Expeditor Wiki contains detailed information related to enabling and collecting trace. For information regarding trace (log) files available and their usage, see the article IBM Lotus Expeditor Logs-What are they good for. This article is designed to be a practical top-down overview for administrators investigating problems within deployed Expeditor applications.
What is Tracing
Tracing is additional debug information written to the platform's log files. For performance reasons, tracing is not enabled by default; it is normally enabled after a problem has been encountered. To view trace files refer to the article Viewing the trace file.
Trace messages are added during the development of an application in anticipation of problems encountered in the field. Such messages may include configuration settings, runtime values, or output of problems encountered during the operation of an application. Most Expeditor applications use JSR47 logging. Because tracing is normally done using JSR47, you can follow a consistent approach to debugging most Expeditor problems. A simple snippet on JSR47 tracing is below.
Tracing has varying levels that control the amount of data written to the trace files. In order of information, they are: CONFIG, FINE, FINER and FINEST. In the above example, the message "The secret is" will be written to the trace file if we enable trace at the FINE level. For practical reasons, it's generally accepted to simply start with the FINEST level to ensure no relevant messages are accidentally omitted.
As indicated IBM support may ask you to enable trace for a particular plugin. For example, the request may appear as "Please enable trace for com.
There are two ways to enable trace, and both have their advantages and disadvantages. Once tracing has been enabled and the problem reproduced, see IBM Lotus Expeditor Support Collecting ISA Data to easily submit trace data to support.
The preferred manner is using dynamic tracing. Support often prefers dynamic tracing because it can be enabled just prior to reproducing a problem. By enabling trace only when needed, the amount of unnecessary information is omitted. Enabling dynamic trace can be found in the wiki article Dynamically adjusting the log level. Additional details on using the OSGI console can also be found in An Overview of the OSGI Console. Using the previous request from support, enabling trace in this manner can be done with the below command.
To enable trace for multiple packages, simply issue the setlogrlev command with the package and level on multiple lines (use enter at the end of each command).
Tracing may be also enabled statically - meaning the trace level will persist after the platform restarts. Because dynamic tracing ends when the platform is restarted, static tracing is helpful when the platform is expected to be restarted (such as provisioning or installation problems) or when the problem may not occur for some time. See the article Configuring platform logging and tracing for details on enabling static trace. Again using support's request, update the rcpi
For multiple packages, add the trace specifications on separate lines. A restart must occur after the rcpi
Pro-actively Enabling Trace
Application users and administrators can be pro-active in problem solving using the following steps.
Common Trace Specifications
Often troubleshooting is a combination of trace specifications. Below are trace specifications for general areas of the product. Assume the FINEST level to be used if not otherwise specified.
Installation (Plugins and Features)
Portlets and Web Applications
Security and Authentication