Thread Dump Logging Utility
Integration Server includes a thread dump log utility that generates a thread dump log containing detailed information that might be useful for debugging. This information includes:
The name of the service executing the thread.
CPU time used by the thread since the JVM started.
Amount of memory currently allocated by the thread.
Any JDBC pool connections the thread might hold.
When the thread dump reporting utility is enabled, Integration Server automatically generates the thread dump reports when one of the following occurs:
The JDBC function pool does not have any available connections.
The percentage of available threads in the server thread pool drops below the watt.server.control.serverThreadThreshold value.
The percentage of available stateful sessions in the session pool drops below the watt.server.session.stateful.warning value.
After one of the above events occurs, Integration Server produces the following sequence of reports:
1. An initial full thread dump report.
2. A second full thread dump report is created 30 seconds after the first report.
3. A third full thread dump report is created 30 seconds after the second.
Integration Server writes the thread dump reports to the following log file:
Integration Server_directory/instances/instanceName/logs/diagnostics/tdump-yyyyddmm-ss-pidprocessID.log
Integration Server writes messages to the wrapper.log when a thread dump log is created. For example:
INFO | jvm 1 | 2024/05/13 07:39:14 | Produced thread dump.
INFO | jvm 1 | 2024/05/13 07:39:14 | Reason: Received signal to dump threads
INFO | jvm 1 | 2024/05/13 07:39:14 |
INFO | jvm 1 | 2024/05/13 07:39:14 | Created thread dump file: /IntegrationServer/instances/default/logs/diagnostics/tdump-2024-05-13_07-39-14-pid2870580.log
After Integration Server creates a set of thread dump logs, at least 10 minutes must pass before one of the conditions discussed above will trigger another set of thread dump logs. This interval is not configurable.
Integration Server limits the disk space used by thread dump logs by setting a disk quota of 50 MB. After 50 MB have been allocated to thread dump logs, when the next thread dump is triggered, Integration Server compresses all existing thread dump log files before producing the new log. After Integration Server has created 50 MB of compressed thread dump logs, when the next thread dump is triggered, Integration Server deletes the second oldest compressed file for a thread dump from disk before creating a new log.
Integration Server uses sever configuration parameters to enable the generation of thread dump logs and control the use of the service names in the logs.
watt.server.diagnostic.threadDumper - Set to true to enable the thread dump logging utility.
watt.server.diagnostic.threadNameWithService – Set to true to include the fully qualified name of the
Integration Server service executing on the thread in the thread dump log.
For more information about these parameters, see
watt.server.The thread dump logs may be explicitly triggered for non-Windows platforms by using the 'kill 'command from a terminal shell. Send kill -USR1 pid. There is no limit on the number or timing of thread dumps created in this manner. When watt.server.diagnostic.threadDumper=true, Integration Server also creates a thread dump log when the kill -USR1 pid command is sent.
Important:
Sending this command to an Integration Server that has watt.server.diagnostic.threadDumper set to false, causes the JVM to exit. In this situation, use the kill -USR1 pid command or create a diagnostic zip instead. However, these alternatives result in Java's standard thread dump report. The additional information provided by the thread dump logging utility will not be included.