On Tue, 30 Jul 1996 m.hampson@??? wrote:
> Is there any way we can get more processes working in parallel on
> such messages?
The quick answer is "not inside Exim", but the new "remote_sort"
parameter does enable you to cause it to deliver to "nearby" domains
first.
> On an more trivial point, can the queue text area in eximon give some
> feedback as to whether a message is currently being processed.
Not easily. The only sure way to tell if a message is being processed is
to open the spool file and try to lock it. (And getting the lock and
immediately freeing it might still prevent Exim from starting to process
the message.) Alternatively one could send SIGUSR1 to all exim processes
and see which one claims to be processing it. Neither method is cheap.
I've noted the requirement though, in case I think of a cunning way of
implementing it. See also [*] below.
On Tue, 30 Jul 1996, Nigel Metheringham wrote:
> I would strongly suggest doing this outside the MTA, and splitting
> the message prior to it hitting exim. I don't know what list
> processor you are using, but several have capabilities of doing just
> that!
Yes, that is my view too. Some of the delays in processing large lists
originate in DNS lookups that take a very long time, especially those
that time out. In theory, one should not make *any* deliveries of a
message until *all* the routing has been done. The reason for this is
that a DNS lookup may cause a non-fully-qualified domain to become fully
qualified, and this may cause the address in the headers to change. You
don't want to send different sets of headers to different addressees.
(For example if someone here mails "ph10@cam" it gets turned into
"ph10@???" by the DNS lookup widening mechanism.)
Exim takes a middle path in this. It tries to route all addresses before
doing any deliveries, but if routing cannot be completed for some of
them (DNS lookup timed out, for example), it carries on and delivers to
those addresses that it can handle at the time.
> However it would be nice if exim *could* effectively split up huge
> delivery sets into multiple smaller sets, but how this would best be
> acheived, and at what point (after routing them all, after directing,
> during delivery...?), is a non-trivial task!
Quite!
On Tue, 30 Jul 1996, m.hampson wrote:
> The way PP does it is to build queues based on outbound MTA.
>
> I don't really know the ins and outs of the exim code but it could
> fork of a master process for a message which then fork of children
> for each rcpt field up to some maximum.
Rationalizations:
(1) The way Exim currently does it makes the code for interlocking very
simple. The way PP does it seems to use a lot of resources and is very
complicated to manage. [*] However, it does mean that it is cheap to
find out which messages are being processed, because there is a central
queue manager with the knowledge.
(2) Because one Exim delivery only ever tries one address at once, a
single message on a busy system cannot monopolize resources.
What I will do:
I will brood about this for a while. It may be that there is some fairly
straightforward way of firing off parallel deliveries once all the
routing has been done. Letting the problem roll around in my head for a
while might cause a spark of inspiration; this has happened before on
other "impossible" ideas.
Thanks for all the feedback.
--
Philip Hazel University Computing Service,
ph10@??? New Museums Site, Cambridge CB2 3QG,
P.Hazel@??? England. Phone: +44 1223 334714
