Job Controller operation under stress

The Job Controller has several self-managing features that work together to aid in managing work load in general, and in particular to  continue to operate successfully even under exceptionally heavy load. Beyond the Job Controller&#x27;s general queueing strategy and creation (and expiration) of Worker Process threads discussed under  Job Controller operation, the  Job Controller&#x27;s    and   options particularly relate to operation under  load.

Under typical circumstances, the Job Controller keeps track in memory of all the active messages (non-  message files) in  the MTA queues. However, to limit its maximum memory requirement, the Job Controller has a configurable limit,  , on how many  messages to track in memory. When the Job Controller&#x27;s   capacity is exceeded, the Job Controller will not  bother to retain in memory information about additional  messages. But in such a case, the affected (excess) message files themselves had already been safely deposited in the MTA&#x27;s store and  forward message queues, where they will be detected later (at which  time normal message processing will resume). At such times of "excess" messages, any enqueuing channel requests to the Job  Controller for immediate insertion of messages into the Job  Controller&#x27;s "queue cache database" list of messages due for  processing are ignored; but it is merely the immediate message  processing that is suspended at such times for the affected messages. The Job Controller will detect any such "excess" message files later, during one of its housekeeping operations, and then begin  delivery attempts for such messages. So   is a limit  on how many messages will get normal/optimal processing (as in  more-or-less immediate processing, in a "first in, first out"  order); but messages that exceed    will be processed  also, eventually.

New in Messaging Server 7.0 is a "stress" feature in the Job Controller, whereby the Job Controller can be informed that channels are  "stressed" and then in response temporarily reduce delivery  jobs on that channel to give the destination some respite. This is primarily relevant for Message Store delivery channels. Besides accepting new messages, the Message Store is also responsible for  responding to end user e-mail client message access requests. So when the Message Store is extraordinarily busy, temporarily reducing the  rate of new message deliveries to the Message Store may allow the  Message Store to instead focus its resources on maintaining  responsiveness to end users; that is, slowing down insertion of new  messages into the Message Store may free up the Message Store to  respond more quickly to e-mail client access to existing mailboxes and  messages.

Message Store delivery channels (  or    channels)  will  automatically inform the Job Controller of stress, when the Message  Store detects that it is stressed. In the case of  channels, when an   channel job is about to shut down, it will query  the Message Store as to whether the store is stressed, and if it is then that    channel job will inform the Job Controller. In the case of LMTP delivery, after each successful delivery into the Message Store the  LMTP server  will query as to whether the store is stressed and if so,  the LMTP server will report that back to the  LMTP client via a special 250 2.3.99 Delivery OK but store under stress success status; the MTA&#x27;s LMTP client recognizes that special status and will then inform the MTA Job Controller of the back end Message  Store stress.

An MTA administrator may also, using the new   command, manually direct the Job Controller to consider  any arbitrary channel to be "stressed".

When the Job Controller is informed that a channel is under "stress", it checks to see if it has already been told this  recently: the Job Controller ignores "stress" alerts that are  received within    seconds of a previous stress alert for  the same channel. But if the stress alert is "new" information, then the Job Controller will multiply the effective    parameter for the  channel by ,  and subtract   from the  effective job limit for the channel. (In the absence of stress, the effective job limit would be simply the minimum of the channel&#x27;s    and the    for the pool in which that  channel runs.1) In addition, the Job Controller will ask all  current master program processes for the channel to exit, and will, if  the message queue for that channel is not empty, start an appropriate  number of new processes: that is, any old processes are shut down and  an appropriate, reduced number of new processes are started in their  place.

But the Job Controller&#x27;s cut back on jobs for "stressed" channels is intended to be temporary, on the presumption/hope that such  a channel should/may "recover" after a time and be able to  return to normal processing levels. The Job Controller attempts to gradually return to the originally configured settings, at step times and step sizes controlled by     and    and , as follows,  (assuming that no further  "stress" alerts or manual   stress  changes are received to further modify the settings and schedule). Automatically,   seconds after the last stress change   (or alternately upon receipt of an    command), the Job Controller divides the effective    by    (never allowing the  effective   to drop below the original  configured  ), and adds    to the  effective job limit (never allowing the effective job limit to rise  above the original configured limit). A "stress change" is either an increase in stress or a decrease in stress.

 1The effective  never goes over 134,217,727, and the effective  job limit never goes below 1.

See also:
 * max_cache_messages Option
 * ims-ms channels
 * LMTP back end TCPIP channel
 * LMTP client TCPIP channels
 * stressblackout Option
 * threaddepth Option
 * maxjobs Option
 * job_limit Option
 * stresstime Option
 * unstressfactor Option
 * unstressjobs Option
 * Job Controller operation
 * Defending against denial of service attacks