On Tue, Oct 07, 2003 at 05:54:35AM -0500, Jerry Jorgenson wrote:
> > In environments where the queues get long and many messages cannot be
> > immediately delivered, the way Exim works is less than optimal. That's
> > unfortunate. If only I could have foreseen just how widely it would be
> > used... Actually, that probably wouldn't have helped much. I knew a lot
> > less in 1995 that I do now.
>
> Do I see an EximII.the.sequel here, with a separate code branch?
I don't think a branch is needed, but here are a few suggestions off the
top of my head which would help the situation:
1) use a DB like tdb or bdb4 as suggested earlier in this thread.
i still haven't looked in to this in detail, so I don't know how to
make fine-grained locking work, or exactly how fine-grained it is
(eg, if yahoo.com goes down, will all my queue runners stall trying
to write to the same row in the db, for yahoo's MX entry? probably)
2) structure the db better.
the current current db uses a simple key/value pair, where the
key is the MX hostname and the value is a long string of message
ID's waiting for delivery. part of the blocking is here; when I
have multiple queue runners trying to write to the same key's
value.. :-)
how can this be improved?
3) it can even be beneficial to *not* use a hints db. maybe have an
which defaults to having the db enabled?
4) i'm sure there are other things, I just can't think of them
quickly :)
