Re: [Exim] Expensive Queue Flushes & Retry

> On Wed, 26 Sep 2001, Chris wrote:
>
> > It seems that flushing the queues are far more expensive than we had
hoped,
> > and one contributing factor seems to be that for a queue run, with, say,
> > ~100k messages in the queue, exim ends up moving onto a new message,
> > forking, and exiting after discovering that the retry time is not
reached.
>
> Yes, I'm afraid that's correct. It has to route all the addresses in the
> message, and then examine the retry times for each of them. With several
> addresses (or several hosts), some may have reached their retry time,
> and some may not.
>
> > Is there any way to have the queue runner process examine the message
> > *before* forking a process to deliver it?
>
> No,[*] because it isn't just examining it. It has to route all the
> addresses to find out which hosts they are aimed for.
>
> [*] Actually, the queue runner does examine the message a bit when it does
> the checks for the -R and -S options, but they are simple checks that

Exim's flexible retry rules are exactly the sort of flexibility we were
looking for in
our fallback host, and have had to implement with queue aging in sendmail to
achive more or less what the Retry section of the configuration file already
offers.

If these great retry rules could be applied less expensively to a large
queue of
already problematic messages, Exim would completely rock as a large fallback
host.

What are your thoughts on having the queue runner do a bit more examination
of a
message before forking a process to attempt it? Could the more trivial
logic that's
run between fork() and wait*() in any way be implemented in the parent?

Cheers.