Job Controller Configuration File
In accordance with the format of the MTA option files, the Job Controller configuration file contains lines of the form:
option=value
In addition to option settings, the file may contain a line consisting of a section and value enclosed in square-brackets ([ ]) in the form:
[section-type=value]
Such a line indicates that option settings following this line apply only to the section named by value. Initial option settings that appear before any such section tags apply globally to all sections. Per section option settings override global defaults for that section. Recognized section types for the Job Controller configuration file are POOL, to define pools and their parameters, and CHANNEL, to define channel processing information and PERIODIC_JOB for the various periodic jobs started by the Job Controller. The PERIODIC_JOB is deprecated and will be removed in a future release. Use the local.schedule.periodic_job configutil parameter instead.
Any options permitted on POOL or CHANNEL sections can be specified at the beginning (general options), thus becoming the default for the option.
The Job Controller configuration file options are described in the following four tables (Table 4-24, Table 4-25, Table 4-26). They are split into general options, pool options, channel options, and stress options groups.
[Table 4-24|#FVKBZ] shows the general Job Controller configuration options.
General Job Controller Configuration File Options
| Option | Description |
|---|---|
| COMMAND | Specifies the command to be run periodically in a PERIODIC_JOB section. The PERIODIC_JOB is deprecated and will be removed in a future release. Use the local.schedule.periodic_job configutil parameter instead. |
| DEBUG=integer | If DEBUG is set to a value other than zero, the MTA writes debugging information to a file in the msg-svr-base/imta/log directory named job_controller-uniqueid, where uniqueid is a unique ID string that distinctively identifies the file name. The imsimta purge utility recognizes the uniqueids and can be used to remove older log files. The value for DEBUG is a bit mask specifying what sort of debugging information is requested: * 1—Trace protocol messages between the Job Controller and other MTA components.
|
| INTERFACE_ADDRESS=adapter | Specifies the IP address interface to which the Job Controller should bind. The value specified (adapter) can be one of ANY, ALL, LOCALHOST, or an IP address. By default the Job Controller binds to all addresses (equivalent to specifying ALL or ANY). Specifying INTERFACE_ADDRESS=LOCALHOST means that the Job Controller only accepts connections from within the local machine. This does not affect normal operation, since no inter-machine operation is supported by the Job Controller. However, this may be inappropriate in an HA environment where an HA agent may be checking if the Job Controller is responding. If the machine on which the Messaging Server is running is in an HA environment, has an “internal network” adapter and an “external network” adapter, and you are not confident of your firewall’s ability to block connections to high port numbers, you should consider specifying the IP address of the “internal network” adapter. |
| MAX_MESSAGES=integer | The Job Controller keeps information about messages in an in-memory structure. In the event that a large backlog builds, it may need to limit the size of this structure. If the number of messages in the backlog exceeds the parameter specified here, information about subsequent messages is not kept in memory. Mail messages are not lost because they are always written to disk, but they are not considered for delivery until the number of messages known by the Job Controller drops to half this number. At this point, the Job Controller scans the queue directory mimicking an imsimta cache -sync command. The minimum value is 10. The default is 100000. |
| REBUILD_PARALLEL_CHANNELS | Specifies how many channel queues are read in parallel on startup and when the job controller is syncing with the disk. Increasing the number can make for a fairer restart when there are massive backlogs, but also has efficiency implications. Default 12. |
| SECRET=file_spec | Shared secret used to protect requests sent to the Job Controller. |
| SYNCH_TIME=time_spec | The Job Controller occasionally scans the queue files on disk to check for any new message files that are missing from the Job Controller’s list of messages that need to be added. By default, this takes place every four hours, starting four hours after the Job Controller is started. The format of the time_spec is HH:MM/hh :mm or /hh:mm. The variable hh .mm is the interval between the events in hours (h) and minutes (m). The variable HH:MM is the first time in a day the even should take place. For example specifying, 15:45/7:15 starts the event at 15:45 and every seven hours and fifteen minutes from then. |
| TCP_PORT=integer | Specifies the TCP port on which the Job Controller should listen for request packets. Do not change this unless the default conflicts with another TCP application on your system. If you do change this option, change the corresponding IMTA_JBC_SERVICE option in the MTA tailor file, msg-svr-base/config/imta_tailor, so that it matches. The TCP_PORT option applies globally and is ignored if it appears in a [{{CHANNEL}}] or [{{POOL}}] section. |
| TIME=time_spec | Specifies the time and frequency that a periodic job is run in a PERIODIC_JOB section. By default, this is /4:00, which means every four hours. The format of time_spec is HH:MM/hh:mm or /hh:_ mm_. hh.mm is the interval between the events in hours (h) and minutes (m). HH:MM is the first time in a day that a job should occur. For example, specifying 15:45/7:15 starts the event at 15:45 and every seven hours and fifteen minutes from then. The PERIODIC_JOB is deprecated and will be removed in a future release. Use the local.schedule.periodic_job configutil parameter instead. |
Table 4-25 describes the POOL option for the Job Controller configuration.
Job Controller POOL Option
| Option | Description |
|---|---|
| JOB_LIMIT=integer | Specifies the maximum number of processes that the pool can use simultaneously (in parallel). The JOB_LIMIT applies to each pool individually; the maximum total number of jobs is the sum of the JOB_LIMIT parameters for all pools. If set outside of a section, it is used as the default by any [{{POOL}}] section that doesn’t specify JOB_LIMIT. This option is ignored inside of a [{{CHANNEL}}] section. |
Table 4-26 describes the CHANNEL options for the Job Controller configuration.
Job Controller CHANNEL Options
| Option | Description |
|---|---|
| MASTER_COMMAND=file_spec | Specifies the full path to the command to be executed by the UNIX system process created by the Job Controller to run the channel and dequeue messages outbound on that channel. If set outside of a section, it is used as the default by any [{{CHANNEL}}] section that doesn’t specify a MASTER_COMMAND. This option is ignored inside of a [{{POOL}}] section. |
| MAX_LIFE_AGE=integer | Specifies the maximum life time for a channel master job in seconds. If this parameter is not specified for a channel, then the global default value is used. If no default value is specified, 14400 (240 minutes) is used. |
| MAX_LIFE_CONNS=integer | In addition to the maximum life age parameter, the life expectancy of a channel master job is limited by the number of times it can ask the Job Controller if there are any messages. If this parameter is not specified for a channel, then the global default value is used. If no default value is specified, 300 is used. |
| NONURGENT_DELIVERY=time | Allows the delivery of non-urgent messages to be scheduled only between certain times as configured. The value is, a set of up to five time windows separated by a comma. Each time window is either a daily window, of the form hh:mm - hh:mm, or is a weekly window of the form day hh:mm - day hh:mm or day hh:mm - hh:mm. In this last case the window is assumed to end on the same day that it began. Examples of windows are: 18:00 - 22:00 which means between 6pm and 10pm each day 20:00 - 06:30 which means between 8pm and 6:30am each night Sat 06:15 - 15:30 which means each Saturday between 6:15am and 3:30pm Wed 12:00 - Fri 00:00 which means between noon Wednesday and midnight between Thursday and Friday. Thus to specify that delivery can be attempted at night or at weekends, you could specify 22:00 - 05:30, Sat 00:00 - Sun 23:59 Up to 5 windows can be specified for each priority levels. |
| NORMAL_DELIVERY=time | Allows the delivery of non-urgent messages to be scheduled only between certain times as configured. The value is, a set of up to five time windows separated by a comma. Each time window is either a daily window, of the form hh:mm - hh:mm, or is a weekly window of the form day hh:mm - day hh:mm or day hh:mm - hh:mm. In this last case the window is assumed to end on the same day that it began. Examples of windows are: 18:00 - 22:00 which means between 6pm and 10pm each day 20:00 - 06:30 which means between 8pm and 6:30am each night Sat 06:15 - 15:30 which means each Saturday between 6:15am and 3:30pm Wed 12:00 - Fri 00:00 which means between noon Wednesday and midnight between Thursday and Friday. Thus to specify that delivery can be attempted at night or at weekends, you could specify 22:00 - 05:30, Sat 00:00 - Sun 23:59 Up to 5 windows can be specified for each priority levels. |
| SLAVE_COMMAND=file_spec | Specifies the full path to the command to be executed by the UNIX system process created by the Job Controller in order to run the channel and poll for any messages inbound on the channel. Most MTA channels do not have a SLAVE_COMMAND. If that is the case, the reserved value NULL should be specified. If set outside of a section, it is used as the default by any [{{CHANNEL}}] section that doesn’t specify a SLAVE_COMMAND. This option is ignored inside of a [{{POOL}}] section. |
| URGENT_DELIVERY=time | Allows the delivery of non-urgent messages to be scheduled only between certain times as configured. The value is, a set of up to five time windows separated by a comma. Each time window is either a daily window, of the form hh:mm - hh:mm, or is a weekly window of the form day hh:mm - day hh:mm or day hh:mm - hh:mm. In this last case the window is assumed to end on the same day that it began. Examples of windows are: 18:00 - 22:00 which means between 6pm and 10pm each day 20:00 - 06:30 which means between 8pm and 6:30am each night Sat 06:15 - 15:30 which means each Saturday between 6:15am and 3:30pm Wed 12:00 - Fri 00:00 which means between noon Wednesday and midnight between Thursday and Friday. Thus to specify that delivery can be attempted at night or at weekends, you could specify 22:00 - 05:30, Sat 00:00 - Sun 23:59 Up to 5 windows can be specified for each priority levels. |
Job Controller Stress Options
When a channel delivery program thinks it is stressed, it notifies the job controller. This design means that the job controller may receive multiple stress notifications.
When the job controller receives a stress notification, it does the following:
- Checks to see whether STRESSBLACKOUT seconds have elapsed since it last processed a stress notification for the channel. If they have not, it ignores the stress notification.
- Multiplies the effective thread depth for the channel by STRESSFACTOR.
- Subtracts STRESSJOBS from the effective job limit for the channel, but never sets it to less than 1.
- Stops all delivery jobs and restarts then according the the new thread depth and job limit
Note that this means that a channel can become multiply stressed.
When the job controller does any work for the channel, at anytime, it checks to see if the channel is stressed. If the effective job limit is less than the configured job limit or if the effective thread depth is greater than the configured thread depth, then the channel is considered stressed. If the channel is stressed, and if STRESSTIME has elapsed since the last stress notification was processed or the channel stress level was reduced, then the job controller does the following:
- Divides the effective thread depth by UNSTRESSFACTOR, but never sets it to less than the configured value
- Adds UNSTRESSJOBS to the effective job limit, but never sets it to more than the configured value
- Starts more processes if the new effective values indicate that they should be started
As an example, given the following configuration:
STRESSFACTOR=10 UNSTRESSFACTOR=3 STRESSJOBS=2 UNSTRESSJOBS=1 THREADDEPTH=5 JOBLIMIT=5
the new effective parameters after the first stress indicator would be
threaddepth=50 joblimit=3
If another stress notification is processed, then the new effective parameters would be
threaddepth=500 joblimit=1
If no further stress notifications were received, then every STRESSTIME seconds, the effective parameters would be changes as follows
threaddepth=166 joblimit=2
then
threaddepth=55 joblimit=3
then
threaddepth=18 joblimit=4
then
threaddepth=6 joblimit=4
then
threaddepth=5 joblimit=5
At this point, the job controller no longer considers the channel stressed.
Sign up or Log in to add a comment or watch this page.