> On Wed, 19 Jan 2000, Ian Southam wrote:
>
> > You seem to get a situation where one awkward message can block up the queue
> > runner and the next one sits behind it waiting for it to finish and the next
> > one ..... Obviously after a while the retry time gets set and the message
> > stops holding things up but, the other active queue runners don't seem to
> > notice (hence stopping the queue).
>
> That would happen with an awkward *domain* rather than an awkward
> message, if there were lots of messages containing addresses for the
> same domain. (Or domainS if they all point to the same host.) The first
> queue runner picks up one message, finds no retry information for the
> host, and so starts to deliver - and gets stuck. The next queue runner
> picks up another message for the same host, still finds no retry
> information, and so also gets stuck... etc. Only after one has failed
> and set the retry information will subsequent ones start skipping. Hmm.
> This is an unfortunate side-effect of the way Exim works. I am not sure
> I can do much about it.
Other than potentially having some way to automatically throttle back
the SMTP related timeout values on domains that are consistently failing.
Not sure how thresholds would be specified, but if a domain has been
failing for 6 days, *I* know that I dont want Exim to wait the standard
2 or 3 minutes to connect - rather, I'd want it to timeout after only
10 or 15 seconds or so. So I end up having to manually change
the timeout values in the config file, and then later change them back.
The question is, if I'm doing this manually, would it be "right" to
have some logic in Exim that says if a domain is failing repeatedly, then
don't force the queue to suffer as a result of that one domain, and require
a lower timeout for future deliveries?
Regards, Dean
--
Dean A. Brooks Email: dean@???
IgLou Internet Services, Inc. Voice: (502) 966-3848
Louisville, KY / USA (800) 436-4456
