On Fri, 2 Sep 2005, Michael Haardt wrote:
>
> And that's pretty much my problem, so I thought about solving it just
> the same. I can see a use for fixed retry intervals, but does anybody
> really care about a geometric interval being met exactly?
Exim doesn't promise to do so; the retry time is just a "do not try
before" time. The actual delivery attempt will not occur until a queue
runner turns up. However the hints database can compensate for this
randomization.
If your problem is within a cluster you control, then it sounds to me like
a configuration error if your front end can hammer your back end to death.
Unfortunately Exim doesn't make it easy to control its rate of outgoing
delivery attempts, so if your front end is also delivering elsewhere (to
the Internet) then restricting the delivery rate to your back end will
hurt other email. Perhaps you should look at tuning the back end so that
it is hurt less by floods of email (queue_only_load, smtp_accept_queue,
smtp_accept_queue_per_connection). Alternatively, you might try separating
the back-end delivery queue from your main queue so that it can be managed
by an Exim with less aggressive parallelism settings.
Tony.
--
<fanf@???> <dot@???>
http://dotat.at/ ${sg{\N${sg{\
N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\
\N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}
