Re: [exim] Exim 5.x

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Phil Pennock
Date:  
À: exim-users
Nouveaux-sujets: Re: [exim] admin defined queue [was Exim 5.x]
Sujet: Re: [exim] Exim 5.x
On 2011-05-19 at 12:35 +0100, Dominic Benson wrote:
> On 19/05/11 11:50, Phil Pennock wrote:
> >
> > New queuing system refers to an approach to scale up the spool directory
> > to something more queue-like, with segregated admin-defined queues (eg,
> > "big_freemail_provider_x"). This is because while Exim is excellent at
> > inbound mail, it doesn't always scale as well as some would like for
> > outbound mail which can't be immediately delivered. Nothing has been
> > done on this. Patches welcome.
> >
> Is this AKA bug 336? It sounds quite interesting, so I think I might
> have a look at making some inroads into the problem.
>
> If there are are any notes/thoughts about behaviour/config/use it would
> be handy to hear them.


I wasn't aware of 336, but yes it's related.

At present, there's split_spool_directory, which divides things up with
one level of hashing, and then some people script their own queue-runner
launchers, running in parallel over sub-trees of the split spool instead
of having the Exim daemon launch runners over everything, which compete
with each other.

Nothing more specific was discussed, that I either recall or find in the
minutes; we all understood the general problem.

If we use a new sub-directory of spool_directory to hold named queues,
then previous Exim installs won't know of the content, but it should be
fairly easy to script a rollback tool which recombines queues into the
original queue.

Thinking briefly (while tired and prone to mistakes):
You'd need a way to declare "move this message to this other queue",
perhaps a way to restrict Routers to only apply to messages in certain
queues (seems optional as a performance optimisation, *could* be useful
for some more sophisticated Router rule bifurcations) and either a way
to control counts of queue-runners per named queue or an API to do so.
Probably best to have a global config option defining a list of allowed
queue names, so that a typo doesn't end up putting 100k messages into
"gmial" where they sit idle. ;)

Beyond that, I think there's a lot of freedom for the implementor to
make their own decisions. :) Have at it!