Re: [Exim] Understanding queue runners

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Philip Hazel
Date:  
À: Michael Haardt
CC: exim-users
Sujet: Re: [Exim] Understanding queue runners
On Fri, 23 Apr 2004, Michael Haardt wrote:

> o  A purely message-based retry database, omitting the transport retry
>    databases.  I don't know if there is a killer argument against this
>    option.


I thought I would be saving some sites a lot of wasted resources when I
invented host-based (as opposed to message-based) retrying. Sigh. :-)

The argument is that if you have 100 messages for one host and have just
tried to connect to it, and failed, there is no point in trying another
99 times. But whether this is a killer or not I don't know.

> o  Multiple queues or an easy to get message attribute that tells the
>    queue runner to not even look at a message for some time.  I don't
>    know how frequently my queue runners actually visit the same message
>    to determine which interval would help.


I had this thought:

Given that Exim updates all the retry information in the top-level
process, right at the end of delivery, I suppose it might be relatively
easy for it to remember the earliest next retry for any address in the
message. This information could be written into a hints file, keyed on
the message id.

At the start of a queue run, after it has obtained the list of message
ids, a queue runner could scan this database and delete those messages
that were too young.

Then I realized that it needs more work to handle new messages that
arrive and do not get immediately delivered because the host's (or
hosts') retry time(s) has/have not yet arrived. Such messages do not
cause any retry updates, so they would have to be handled differently,
and in multiple processes. Ugh. This starts to feel far too messy.

> The parent could open a pipe and collect data for a -J file, creating
> one and storing the data in it, if it receives any. Or does the client
> also need to read the file?


The whole point of having the -J file open and ready is that Exim can
write to it *fast* when a delivery is complete. This minimizes the
window during which a system or process crash will result in a double
delivery.


--
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