[EMAIL PROTECTED] wrote:
I believe I understand, but only from the very highest altitudes. It seems
to me that there might be many places where it could be an issue, or that
it could just as easily not be. I haven't seen any of the pollserver code
or anything to suggest how it does what it does. (Is it that pollserver
requires everything to be able to do its own thing at any point in time,
or is it just that running everything sequentially for each connection
will slow things down? If it's just as fast as forkserver should that
happen, I could probably live with that, but if its actually prone to
breaking, then it's not for me.
If you ever do get some good documentation together on pollserver and/or
async programming, please announce it. Thanks.
We've been running qpsmtpd-async on 7 servers with upwards of 5M emails
per day each for about 6 months, and it's quite stable. Most of these
are 4-5 year old Sparc Solaris boxes. (Finally got a recent enough
Linux to try it on - it was momentarily handling sustained test loads in
excess of 1000 emails/second). It's not in production on real email yet
- that's largely because our filter installation requires a lot more
than just spam filtering engines.
I've not had to dig very deep into async programming at all, despite
having had to at least tweak (or write from scratch) ALL of the plugins
we use.
We'll probably go into production with few async-specific plugins
(tweaked async DNSBL and TLS plugins). ClamAV and SpamD aren't, and it
doesn't look like we _need_ the forwarder to be async either.
I'd use the qpsmtpd async forwarder plugin, but the outbounds of the
thing needs to do failover, and I've not studied the async plugin enough
yet.
We've had to tweak almost all plugins for "common" reason/plugin
scheduling/uniform rejection modes/logging/quarantining techniques, as
well have a more-or-less equivalent filter tuning regime as our
pre-existing (non-qpsmtpd) filters.
