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.
|