On Mon, 6 Dec 2004, Michael Haardt wrote:
> If a message has many recipients, it may start a bunch of deliveries.
> Typical newsletters without VERP thus avoid the otherwise controlled
> parallelism after a failure like too high local load, possibly resulting
> in a new load peak.
Indeed, but remember my original design parameters: the assumption is
that most deliveries will happen first time, NOT via a queue runner. I
hadn't thought about high load issues at that time (the various load
controls were all added to Exim later).
> Would anybody object if the choice were only a) to delay delivery of
> B until all messages were transmitted to the host for A or b) never to
> send messages down the same channel?
Not quite so simple. If you have remote_max_parallel set greater than
one, delivery to A and B may be happening simultaneously, in different
processes that cannot communicate with each other. So the only way to do
(a) would be to set remote_max_parallel=1, which is probably not a good
idea. And doing (b) removes an important optimization that sometimes is
very helpful. Making it an option is no problem; making it the default
isn't right.
> Neither would need a pipe, thus making multiple deliveries from one
> queue runner very easy.
It isn't particularly hard managing an array of pipes. That is, in fact,
what the delivery process already does in order to implement
remote_max_parallel. Each delivery subprocess passes back information
about what happened using a pipe.
> Yes, but it's just one host, so using fixdb to change its record causes
> delivery of all messages.
Ah! Somebody that is brave enough to use fixdb... congratulations! I
wasn't thinking of that.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
