After, urgentafter, normalafter, nonurgentafter, secondclassafter, thirdclassafter Channel Options

From Messaging Server Technical Reference Wiki
Jump to: navigation, search


Service job execution deferral (after, urgentafter, normalafter, nonurgentafter, secondclassafter, thirdclassafter)

Service jobs are created to deliver messages; the creation of such jobs on an as-needed basis is managed by the MTA's Job Controller. The creation of service jobs can be deferred using the after channel option, or deferred on a priority-sensitive basis using the other *after channel options. Note, however, that such deferral is seldom of interest given the modern Job Controller's internal, "smart" management of jobs.

Each *after option accepts an argument specifying either an absolute time at which to initiate a delivery job, or an amount of time to delay (a delta time). For the Messaging Server MTA, if the argument is an unsigned integer value, it is interpreted as an absolute time at which to initiate a delivery job, in GMT time zone; if the argument begins with the plus character, +, it is interpreted as the number of seconds by which to defer the execution of the job -- a delta time value. (Note that for PMDF, the argument syntax was different: all values were interpreted as delta time values.)

Historical note: For PMDF, deferred execution with a (typically small) delta time value was most often used to increase throughput (e.g., as a result of cutting down on process creation overhead) for heavily used channels. By using after to introduce a slight latency in the creation of a service job, each such job had a window of time during which to "collect" all the messages sent to the channel in that time. Whereas otherwise a service job might handle only one (or at especially busy times perhaps two or three) messages, such use of after allowed a service job to handle larger numbers of messages. For channels with high connection or process activation overhead, this could result in higher overall throughput. But this is no longer the case for the Messaging Server MTA.

Separate deferral settings are allowed for messages with different effective priority values. The urgentafter channel option sets the delay for urgent messages, normalafter sets the delay for normal priority messages, and nonurgentafter sets the delay for non-urgent messages. secondclassfter and thirdclassafter set the delay for second-class and third-class (nonstandard priority levels below non-urgent) messages respectively. after sets the delay for all messages regardless of priority; setting it is equivalent to setting all of the other *after options to that same delay value.


See also: