Monitoring dispatch requests

Use the dispatch progress monitor (DPM) to gather, at specified time intervals, data about a dispatched request if that dispatched request is still being processed after this time interval elapses. After the data is gathered, a new time interval starts. As with the first time interval, when this time interval elapses, the data is gathered again. As long as the DPM is active, and the request is still running in the servant, the data continues to be gathered at the end of each time interval.

Before you begin

Determine for which type of protocols you want to monitor requests. You can configure DPM to collect the data for requests that use the IIOP, HTTP, HTTPS, MDB, SIP, or SIPS protocol. You can also configure DPM to collect the data for requests from the CRA that are directed through the controller for queuing to a servant.
Determine how frequently you want DPM to collect the data about each request. For example, you might only want to collect data for long running requests. In this situation, set the interval to a length of time that prevents the data from being collected for requests that complete quickly.
Determine the type of data that you want DPM to collect at the end of each time interval. You can configure DPM to take an SVC dump, a Java™ core dump, a Heap dump, a Java Tdump, or to collect traceback data.

About this task

If DPM is not active for the protocol that a request is using, such as HTTP or IIOP, when the request is dispatched into the servant, DPM does not monitor that request. Even if you issue the modify command to dynamically enable DPM for that protocol after that request is dispatched, DPM does not monitor the request. After DPM is enabled for a protocol, DPM only monitors new requests that use that protocol.

The DPM interval and the dump action are initially obtained from the WLM classification file. The modify DPM command overrides these values for the entire server. Resetting a DPM interval or the dump action turns off the override so that the values for the reset parameters are again obtained from the WLM classification file.

If DPM is active for the protocol that is being used for a request, before that request is dispatched in the servant, you can make dynamic changes. The dynamic changes can be to the specified time interval and the dump action that you want performed. Any dynamic changes that you make take effect at the end of the current interval for a dispatched request, and starting with first interval for new requests.

Procedure

Issue the following modify command to configure and enable DPM:

f server,dpm,[IIOP=nnn | HTTP=nnn | HTTPS=nnn 
| MDB=nnn | CRA=nnn | SIP=nnn | SIPS=nnn | OLA=nnn | INTERVAL=nnn 
| dump_action=xxx | clear_all | reset_all]

In this command:

The nnn placeholder specifies, in seconds, the length of the time interval for a specific protocol type or for a CRA request. The value for nnn placeholder must be an integer 0 - 255, or reset. A value of 0 means that the protocol has no interval and that DPM is disabled for requests that use that protocol. A value of reset means that the control of the DPM interval is returned to the WLM classification file.
Valid values for the xxx placeholder are SVCDUMP, JAVACORE, HEAPDUMP, TRACEBACK, JAVATDUMP, NONE, or RESET. A value of RESET means that control of the dump action is returned to the WLM classification file.
A value specified on the INTERVAL parameter sets the DPM interval for all six protocols to the same value.
The clear_all value sets the time intervals for all related request protocols to 0 and the dump action to None.
The reset_all value resets all the DPM intervals and the dump_action parameter. Control of the DPM intervals and the dump action are returned to the WLM classification file.

When you specify a non-zero value for one or more of the DPM-related protocols, you automatically enable this functionality for those protocols. To disable DPM for specific protocols, set the parameter for that protocol to 0. To disable DPM for all the DPM-related protocols, set the dump_action parameter to NONE. This setting overrides any value specified for the parameter for a specific protocol.

Results

When DPM is active for a protocol, and traceback data is collected when the time interval elapses, information, similar to the following example is written to your server log file:

BossLog: { 0175} 2008/05/05 12:16:01.418 01 SYSTEM=SY1 SERVER=BBOS001
   PID=0X00010144 TID=0X00000034 0XF6FAF20  c=./bbgrjtr.cpp  at line:+885 ...      
BBOJ0118I: ThreadDetails: ASID = 005B, TCB = 0X008CBE88, Request = fffff503, 
   Is JVM Blocked = false, Tried to interrupt = false, Given up = false, 
   Internal Work Thread = false, Hung Reason = Not Hung, 
   SR Dispatch Time = 2008/05/05 12:15:31.371625, 
   CTL Receive Time = 2008/05/05 12:15:31.366693, 
   CTL Queued to WLM Time = 2008/05/05 12:15:31.371328, 
   Details = , ODI Details = .JVM INTERRUPTIBLE THREAD, Monitor ACTIVE.
BossLog: { 0176} 2008/05/05 12:16:01.423 01 SYSTEM=SY1 SERVER=BBOS001  PID=0X00010144 
   TID=0X00000034 0XF6F9DE0  c=./bbgrjtr.cpp  at line:+885 ...            
BBOJ0117I: JAVA THREAD STACK TRACEBACK FOR THREAD WebSphere:ORB.thread.pool t=008cbe88:  
   Dispatch Progress Monitor  
   Traceback for thread WebSphere:ORB.thread.pool t=008cbe88: 
   com.ibm.ws390.orb.ClientDelegate.invokeRequestCFW(Native Method)  
   com.ibm.ws390.orb.ClientDelegate.commonInvoke(ClientDelegate.java:998)
   com.ibm.ws390.orb.ClientDelegate.invoke(ClientDelegate.java:845)   
   org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:484)  
   com.ejb.test.hello.second._SayHelloSecondHome_Stub.create(_SayHelloSecondHome_Stub.java:207)  
   com.ejb.test.hello.first.SayHelloFirstBean.sayHelloOne(SayHelloFirstBean.java:76)  
   com.ejb.test.hello.first.EJSRemoteStatelessSayHelloFirst_67c1d243.
         sayHelloOne(EJSRemoteStatelessSayHelloFirst_67c1d243.java:41)

What to do next

View the current DPM settings. You can issue the following display command if you want to check the current settings for DPM:

f <varname>server</varname>,display,dpm

The following message displays in response to this command:

BBOO0361I DISPATCH PROGRESS MONITOR (DPM) SETTINGS:  IIOP(000):HTTP(010):HTTPS(015)
:MDB(000):SIP(020):SIPS(000):OLA(000),DUMP_ACTION  (JAVATDUMP)

Starting with Version 8.5.5.1, a message similar to the following message displays in response to this command:

BBOO0361I DISPATCH PROGRESS MONITOR (DPM) SETTINGS:   
IIOP(000):HTTP(000):HTTPS(015):MDB(000):SIP(020):SIPS(000):OLA(000):CRA(015) DUMP_ACTION(TRACEBACK)
BBOO0188I END OF OUTPUT FOR COMMAND DISPLAY,DPM

Modify the dump action that you want DPM to perform. You can use the modify command or the server_region_dpm_dump_action WebSphere® variable to modify the dump action that you want DPM to perform.
To use the modify command to modify the dump action that you want DPM to perform, issue the following command, specifying the appropriate dump action:
```
f server,dpm,dump_action=[SVCDUMP | JAVACORE | HEAPDUMP | TRACEBACK | JAVATDUMP | NONE ]
```
To use the server_region_dpm_dump_action WebSphere variable to modify the dump action that you want DPM to perform, complete the following actions:
1. In the administrative console, click Environment > WebSphere variables.
2. Select the appropriate node or cell from the list of available servers, nodes and cells, and then click New.
3. Specify server_region_dpm_dump_action in the Name field, and SVCDUMP, JAVACORE, HEAPDUMP, TRACEBACK, JAVATDUMP, or NONE in the Value field.