Information about output stream configuration is stored as XML data. All Isode applications will load the XML contained in the file logtailor.xml, if it exists, at startup. The search path for logtailor.xml is first $(ETCDIR), and then (SHAREDIR). The filename and location can be overridden if required by defining the environment variable LOGTAILOR to be an alternative filename or filepath.
An application may then load a private stream configuration. For Isode Message Switch components , this is contained in the mtalogging.xml file, located in either $(ETCDIR) or (SHAREDIR).
When using the Message Switch in a Directory-based configuration, the master version of this configuration is actually held in the Directory, and is editable using MConsole. The isode.tailord process then downloads this information and creates an mtalogging.xml file for other processes to read.
When using the Message Switch in a table-based configuration, the mtalogging.xml file must be edited directly, using the standalone logconfig GUI.
15.3
Queue Manager
As MConsole is used to monitor and control Queue Manager, it may be helpful to consider the role of Queue Manager (isode.pp.qmgr) before describing the MConsole application. The Queue Manager performs three basic functions:
• Manages the message queue by scheduling sequences of programs (channels) to process the recipients of a message
• Connects to the Directory holding the MTA configuration and downloads the information required to generate the mtatailor file and mtalogging.xml
• Acts as a the server for the SOM protocol which enables clients such as MConsole to send commands and receive responses.
The Queue Manager operates normally without reading the queue on disk. However, it does read the queue on disk on startup and periodically, to check for any messages submitted which it does not know about. At the same time, the Queue Manager will remove files from the queue which are not associated with a message and which are older than a configurable age.
15.3.1
How Queue Manager starts a channel
When a channel is invoked by Queue Manager (qmgr), the channel connects back to the qmgr and is given work to do by it. Although qmgr controls the channel, it is the channel which accesses the queue directly.
Some channels are not started by the qmgr; these include:
• inbound protocol channels such as the SMTP server (smtpsrvr),
15.3.2
Cleanups, timeouts, and warnings
When all recipients for a message have been processed, the message is deleted from the queue by the last channel processing the message. (However, you can configure the MTA to leave messages on the disk). The MTA calculates a latest delivery time for each message. If that time is reached, the message is non-delivered. The operator can also force
non-delivery or deletion of a message using MConsole. If warnings are configured, when the message has been in the queue for the warning interval, a warning message is generated and sent to the message's originator. Multiple warnings can be generated at the warning interval.
When action on a message is required, such as generating a non-delivery or delivery report, or a warning message, this action is performed by the housekeeper channel.
15.3.3
Queue Manager controls and tailoring
The Queue Manager program has some command line flags which can be used to control its behaviour when it starts. On Microsoft Windows, these can be passed as service arguments.
debug
‘debug’ mode. Normally the program will detach, or attempt to run as a service on Windows. This flag prevents this, and enables the queue manager to run in the foreground. This must be the first argument.
-s
Single shot mode. The program will see if the tailoring information needs to be updated from the Directory, and create a new mtatailor file etc. if required. It will then exit. This is useful for checking the mtatailor file without starting the MTA.
-D
Disable all outbound channels. This sets all outbound channels into the disabled state when the queue manager starts. They can be enabled using the console, perhaps for just some channels.
-S
Disable submission on all inbound channels. Submission can then be enabled using the console for certain channels.
-b
Run the queue manager in "benchmark" mode. See the M-Switch Advanced Administration Guide for more details.
The queue manager checks the Directory server for configuration changes at the interval set by the Configuration reload interval (qmgr_config_time). The queue manager listens on two different addresses. The Channel address (qmgr_chan_address) is used by channel programs, and the SOM address (qmgr_som_address) is that used by MConsole and the EventViewer.
The queue manager will scan the queue on disk at an interval which can be set in the Queue Manager tab (qmgr_load_interval)– it defaults to 6 hours (qmgr_load_interval). Files which are not part of a valid message will be removed if they are older than the Trash lifetime (trash_lifetime).
15.3.4
Tuning the Queue Manager
The Queue Manager has to:
• decide which message and recipients to process next • decide when to process the message
• control starting channel processes • create connections to peer MTAs • deal with retrying after temporary errors.
There are a number of controls which can be used to tune the behaviour of the queue manager.
The default configuration is optimised to ensure that the system on which it is running is not overloaded, rather than to maximise performance and throughput. For a very busy system it is important that you read this section if you need the queue manager to process messages as quickly as possible.
The simplest way to configure the queue manager to optimise for throughput is to change the following values:
• Maximum operation rate (qmgr_oprate_max): to about 2000
• Idle connection timeout (qmgr_conn_hold_time): to about 5 (seconds)
15.3.4.1
Overall processing
You can limit the number of channel process which run at any time using Maximum channel processes (qmgr_max_chanproc).
However, the main limit on the overall processing is normally through the Maximum operation rate (qmgr_oprate_max). The operation rate is the rate at which messages are processed by channels, and will scale roughly with the use of the local CPU and disk resources. Therefore, for a given hardware system, there is a natural limit. If the current operation rate exceeds the operation rate limit, then the queue manager will delay processing the message until the rate has fallen. The operation rate which is used depends upon the message priority.
The maximum operation rate applies to the highest priority messages, and the limit which is applied is reduced in the Reserve operation rate (qmgr_oprate_reserve) band. This is expressed as a percentage of the maximum operation rate. The 'unreserved' fraction of the operation rate is available for messages of any priority. The object of this is to enable a systems administrator to ensure that there are hardware resources available for messages of higher priority.