On Mon, Aug 06, 2001 at 01:07:36PM +0100, Richard Underwood wrote:
[snip]
> Read what I wrote again. It IS qmail's fault. One role I use qmail
> for is to accept mail which is then passed on to an exchange server on the
> same network. Here's an example of what can happen ...
>
> If the exchange server goes down, a large queue builds up. The
> exchange server accepts something like 20 concurrent connections before
> refusing to accept connections. This, as you say, is what the server should
> do.
Yes, that is absolutely correct.
> When the exchange server comes back up, I kick the qmail-send
> process to get it to deliver the queue. At this point I should be able to go
> off and do other things.
Why are you kicking qmail-send? That should never be necessary in a
production environment.
> However, qmail tries to send the queue with lots of concurrent
> connections. The first 20 work, but the rest are dropped. This then blocks
> any further attempts for a time. After this time, the mails are tried again
> - once more, lots of concurrent connections, more dropped connections, more
> delays.
If this box' only function is relaying to the exchange server, why not
set concurrencyremote to 20?
> In the end, I resort to sitting there watching the queue and kicking
> the qmail-send process until the queue is small enough to go through without
> help.
Have you tried not kicking it at all? qmail has a very efficient retry
schedule, that doesn't even bog down heavily loaded servers.
[snip]
> Saying that there's no room for improvement on qmail's side is pure
> arrogance. Just look at the number of patches available for it for a clue.
> qmail is great, it works well, but it still could be improved.
Lots of patches satisfy needs easily fixed without patches. Lots of
patches satisfy needs that only a few users have.
Some patches are useful to me. Some are useful to you. Fact remains
that vanilla qmail-1.03 does just about everything one could need.
And if you don't like this behaviour: write a patch (or find one), or
stop using qmail. Nobody is forcing you to use qmail.
> People complain about single message blocking their queue ... Run
> two copies? That works, but is it the best option? A configurable limit to
> the threads per message would fix this. Prioritizing messages would be
> better.
It is the best option to me. Not because of single messages blocking
the queue, but because I like my user-to-user emails to be instant and
not be delayed in *any* way by mailinglist traffic.
Greetz, Peter
--
Against Free Sex! http://www.dataloss.nl/Megahard_en.html
