You can tune a variety of settings for the "MDB throttle", to control the amount of MDB work that the server processes at a given time.
The MDB throttle support maintains a count of the current number of in-flight messages for each listener port.
The in-flight count is decremented by 1 whenever the controller is notified that a work record for this Listener Port has completed (whether or not the application transaction was committed). After being decremented, the in-flight count is checked against the low threshold value for this Listener Port. If the in-flight count drops down to the low threshold value, the previously-blocked queue agent thread is awoken (notified). At that point new work records can be queued onto the WLM queue. That is, the throttle has been "released".
The low threshold and high threshold values are set externally by one setting, the listener port Maximum sessions parameter. The high threshold value is set internally equal to the Maximum sessions value defined externally. The low threshold value is computed and set internally by the formula: low threshold = (high threshold / 2), with the value rounding down to the nearest integer.
However, if the Message Listener service has been configured with the Custom Property of MDB.THROTTLE.THRESHOLD.LOW.EQUALS.HIGH defined and set to a value of "true", then the low threshold value is set internally to the high threshold value (which is the externally-set Maximum sessions property of the listener port).
You should set the listener port "Maximum sessions" value to twice the number of worker threads available in all servants in the scalable server (2*WT) so that, if you have an available worker thread in some servant, you do not leave it idle because of a blocked MDB throttle. That is, you do not want to have an empty WLM queue, an available servant worker thread, and a blocked throttle.
Furthermore, by setting the high threshold to 2*(WT+N) you can ensure that, at the moment a servant worker thread frees up and releases the throttle, there is a backlog of N messages pre-processed and sitting on the WLM queue ready for dispatch. However, setting a very high value introduces the WLM queue overload problem that the throttle was introduced to avoid. Note that this scenario assumes that the queue (or topic) is fully-loaded with messages to be processed.
Therefore raising the high threshold value allows the server to create a small backlog of preprocessed messages sitting on the WLM queue if a workload spike occurs. However, raising the high threshold value also increases the chance that a work record for a given message might time out before the application can be dispatched with the given message. That is, the server might reach the MDB Timeout limit. The given message is eventually re-delivered to the server, but only later and the processing done up until that time would be wasted. Also, a very large high threshold value would effectively bypass the MDB throttle function, in which case the WLM queue could be overloaded; this would cause the server to fail.
Although the scalable server was designed with the goal of maximizing throughput, it is possible to use the listener port settings to achieve other workflow management goals.
For example, a high threshold setting of ‘1' guarantees that messages are processed in the order that they are received onto the destination.
There might also be other business reasons, based on capacity or other factors, to restrict a particular listener port to much less concurrency than the server would otherwise support. Although this is certainly a supported configuration, it might cause the throttle to block when there are idle worker threads available.
Suppose your server is configured with the maximum server instances value set to 3, with workload profile of IOBOUND. You have two CPUs, therefore WebSphere® Application server will create six worker threads in each servant. Your application (a single MDB mapped to a queue) handles each message relatively quickly (so there is less risk of timeout) and you want the total time from arrival of a given message on your MDB queue until the end of MDB dispatch for this message to be as small as possible.
To provide a quick response time for a surge in work, you opt for a bigger backlog. You set your Listener Port maximum sessions value to 100 = 2 * (3 * 6 + 32).