Re: [exim] Should queue processing be rewritten in Exim?

Quoting Marc Perkel (marc@???):

> Suppose Exim had 2 queues instead of one. We'll call the first queue the
> primary queue which is a ram drive and the secondary queue which is a
> disk drive. All this is of course optional and user settable.

Having queues in ram is, as i pointed out in my earlier posts about
'large exim setups', a workaround for Exim's (rather poor) way of
handling large queues.

I would *not* opt for a configuration option to store the queue in ram,
as this can easily be configured with some tricks, and it still is a
workaround for a problem instead of a solution.

Other MTA's -can- manage large queues, and for what i know, without
storing them in ram with the risk of losing data. Stop focussing on
ramdrives and queues in memory, instead, focus on -why- it is Exim is
slow with large queues.

These are just my $0.02

-Sndr.
--
| Support bacteria. They're the only culture some people have.
| 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D