SMTP_STRICTLY_ROUND_ROBIN

This configuration variable directs the LISTSERV SMTP workers to handle outbound MAIL files using strict "round-robin" delivery to the outbound MTA.

An option for strict "round-robin" delivery to the outbound MTA via LISTSERV SMTP worker processes has been added to the Windows version of LISTSERV.

Activation of this feature tells the SMTP workers, if plural, to only process messages whose spool ID is congruent to their worker ID modulo the total number of workers. In other words, they only process their fair share of messages. Messages without a numeric spool ID, such as those created manually or by debug scripts, are "free for all" and will be processed by the first worker that sees them. The SMTP worker log files (x:\LISTSERV\LOG\SMTPS#n-yyyymmdd.LOG) will have a message at the top confirming that the feature has been activated.

Drawback: If a worker should die, some messages will be left unprocessed. In practice, we have never ever seen a worker die unless there is some kind of global system problem, like a disk crash or out of swap space condition (not counting workers that abort due to a configuration error). But, in theory, it could happen. Another potential drawback is more cycles spent scheduling workers since a short burst of messages will require the participation of each and every worker. L-Soft does not believe that it will be a very significant difference except in low-volume, many-worker scenarios (in a high-volume scenario, workers are not very often in wait state, and it does not matter from a resource utilization standpoint which messages they pick and on which criteria).

Important: This feature is incompatible with worker pools. Any workers placed in a pool will ignore SMTP_STRICTLY_ROUND_ROBIN=1 and process all messages for the pools they are currently enabled for. Workers not in a pool, if any, will honor the option, and this is likely to lead to unprocessed messages. This feature cannot be implemented for pools without major work because the workers do not communicate with each other. This means that they cannot maintain a catalogue of all pools currently active and how many workers are currently working on what pools.

It should be made clear that any imbalances in load sharing are outside LISTSERV. By default (that is, without SMTP_STRICTLY_ROUND_ROBIN=1), the various workers are synchronized using a single, shared event flag. LISTSERV sets the event flag when there is a new message to process. Because there is only one event flag, LISTSERV could not possibly be favoring a particular worker, or ignoring a particular one. All the workers wait on this event flag when they run out of work, and Windows decides which of the workers to wake up if several are waiting (only one is awakened). Windows does not know that they are numbered #1, #2, etc. They are just different processes as far as Windows is concerned. All tests done so far have shown that Windows seems to use a round-robin algorithm. Simulations have all shown approximately the same number of wakeups for every process.

However, our simulations were based on pseudo-workers that did a variety of things at the same speed. If for any reason a worker is slower (typically because it is talking to a slower MTA), it will tend to be busy when the other workers are waiting for new work. That is, there will tend to be a more-than-fair occurrence of the state where all workers are waiting except for the slow worker, which is still busy finishing its last message. At that point it is guaranteed that the next message will be processed by one of the fast, waiting workers. This dynamic load balancing is by design. MTA speed can vary significantly in the space of a few minutes, and the workers adjust their respective shares accordingly and without human intervention. The result is more messages to workers (and thus to MTAs) that have more capacity right now, though this can change in only a few minutes.

Thus a slower target server will normally lead to a less-than-fair share of messages. The purpose of SMTP_STRICTLY_ROUND_ROBIN=1 is to enforce a fair share for all workers by earmarking messages for a particular worker.

The default value is 0 (disabled).