Typically, you would add additional pool definitions to the Job Controller configuration if you wanted to differentiate processing of some channels from that of other channels. You might also choose to use pools with different characteristics. For example, you might need to control the number of simultaneous requests that some channels are allowed to process. You can do this by creating a new pool with the job limit, then use the pool channel keyword to direct those channels to the new, more appropriate pool.
In addition to the definition of pools, the Job Controller configuration file also contains a table of the MTA channels and the commands that the Job Controller must use to process requests for each channel. The two types of requests are termed “master” and “slave.” Typically, a channel master program is invoked when there is a message stored in an MTA message queue for the channel. The master program dequeues the message.
A slave program is invoked to poll a channel and pick up any messages inbound on that channel. While nearly all MTA channels have a master program, many do not have or need a slave program. For example, a channel that handles SMTP over TCP/IP doesn’t use a slave program because a network service, the SMTP server, receives incoming SMTP messages upon request by any SMTP server. The SMTP channel's master program is the MTA’s SMTP client.
If the destination system associated with the channel cannot handle more than one message at a time, you need to create a new type of pool whose job limit is one:
[POOL=single_job] job_limit=1
On the other hand, if the destination system has enough parallelism, you can set the job limit to a higher value.
Example 10–1 shows a sample Job Controller configuration file. Table 10–6 shows the available options.
!MTA Job Controller configuration file ! !Global defaults tcp_port=27442 (1) secret=never mind slave_command=NULL (2) max_life_age=3600 (3) ! ! !Pool definitions ! [POOL=DEFAULT] (4) job_limit=10 (5) ! [POOL=LOCAL_POOL] job_limit=10 ! [POOL=IMS_POOL] job_limit=1 ! [POOL=SMTP_POOL] job_limit=1 ! !Channel definitions ! ! [CHANNEL=l] (6) master_command=msg_svr_base/lib/l_master ! [CHANNEL=ims-ms] master_command=msg_svr_base/lib/ims_master ! [CHANNEL=tcp_*] (7) anon_host=0 master_command=msg_svr_base/lib/tcp_smtp_client |
The key items in the preceding example (numbered, enclosed in parentheses, and in bold font) are:
This global option defines the TCP port number on which the Job Controller listens for requests.
Sets a default SLAVE_COMMAND for subsequent [CHANNEL] sections.
Sets a default MAX_LIFE_AGE for subsequent [CHANNEL] sections.
This [POOL] section defines a pool named DEFAULT.
This [CHANNEL] section applies to a channel named l, the UNIX local channel. The only definition required in this section is the master_command, which the Job Controller issues to run this channel. Since no wildcard appears in the channel name, the channel must match exactly.
This [CHANNEL] section applies to any channel whose name begins with tcp_*. Since this channel name includes a wildcard, it will match any channel whose name begins with tcp_.
The Job Controller creates and manages channel jobs for delivering messages. These channel jobs run inside processing pools within the Job Controller. A pool can be thought of a “place” where the channel jobs are run. The pool provides a computing area where a set of jobs can operate without vying for resources with jobs outside of the pool. Note that the job limit that is set in the job_controller is per pool. So, for example, if you have your SMTP_POOL defined with a job_limit of 10, then only 10 tcp_smtp client processes can run in that pool at any given time.
There are situations where one may want to create additional tcp_* channels (say, for example, a tcp channel for particularly slow mail sites). It is a good idea to have these channels run in different pools. The reason for this is if we created ten different tcp_* channels and they were all running in SMTP_POOL, it is possible to only have one tcp_smtp client running per tcp_* channel at any given time (depending on whether or not there is mail destined for all the tcp_* channels and given that SMTP_POOL defined with a job_limit of 10). Assuming there is heavy load on the system and that all queues have messages waiting to go out the various tcp_* channels, this would not be efficient. It is much more likely that one would want to define additional pools for the additional tcp_* channels so that there is no contention for slots.
For example, suppose we set up the following tcp_* channels:
tcp_yahoo smtp mx pool yahoo_pool keyword keyword keyword tcp-yahoo-daemon tcp_aol smtp mx keyword keyword keyword pool aol_pool tcp-aol-daemon tcp_hotmail smtp mx pool hotmail_pool keyword keyword keyword tcp-hotmail-daemon ... tcp_sun smtp mx pool sun_pool keyword keyword keyword tcp-sun-daemon |
In order to add have ten tcp_smtp_client processes for each of the new channels we would add the following in the job_controller.cnf file:
[POOL=yahoo_pool] job_limit=10 [POOL=aol_pool] job_limit=10 [POOL=hotmail_pool] job_limit=10 ... [POOL=sun_pool] job_limit=10 |
For more information about pools, see Processing Pools for Channel Execution Jobs see the Sun Java System Messaging Server 6 2005Q4 Administration Reference.
Table 10–6 Job Controller Configuration File Options