Configuration of Quiesce/Resume Function for Process Choreographer
 Technote (troubleshooting)
 
Problem(Abstract)
Process Choreographer has a quiesce/resume feature. The retention queue retry limit and retention queue message limit values are configurable.
 
Resolving the problem
Short description of the Quiesce/Resume Feature

The Business Process Container provides a quiesce/resume feature which is described here.

The retention queue is a buffer for messages that cannot be processed temporarily or permanently. If the buffer is full, the system switches to quiesce mode.

If the system is in quiesce mode, the system sleeps for two seconds for every message that is received. That prevents the system from using a lot of resources for processing messages that most likely cannot be processed anyway because of some temporary infrastructure failure. If any message can be processed sucessfully, the system switches back to the normal processing mode. If a message is passed to the retention queue for a few times, this message is said to be corrupted and therefore copied to the queue for unprocessed messages.

There are two parameters regarding this feature configurable:

  • "Retry Limit"
  • "Retention Queue Message Limit"

The parameters can be found in the admin console:

Servers


-> Application Servers

-> <servername>

-> Business Process Container

Hints for setting the Quiesce/Resume parameters

There may be scenarios, where the default behavior is not appropriate. Therefore it might be neccessary to adapt these parameters. Some Hints can be found in the following sections:

It is possible to prevent the system from switching to the quiesce mode too early by setting the "Retention queue message limit" value to a large value.

On the other hand there might be scenarios where already one failed message is critical, in those cases it is possible to set the "Retention queue message Limit" to a small value (e.g. 0).

Then the system switches to quiesce mode earlier.

The second parameter "Retry Limit" says, how often a message may be put into the retention queue and back into the internal queue. Messages that are passed to the retention queue for that many times, are copied into the queue for unprocessed messages (a.k.a. hold queue).

In scenarios, where infrastructure is very reliable and applications are performance critical, the retry limit should be small (e.g. 1). Then messages that failed once are copied into the hold queue and are not dispatched twice.

In other cases, where infrastructure might fail more often, it is recommended to chose a larger value for the retry limit. that prevents messages to be filtered out too early.

 
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Enterprise Edition (EE)
Operating system(s): Windows
Software version: 5.1
Software edition:
Reference #: 1106925
IBM Group: Software Group
Modified date: Apr 3, 2003