Folks,
I have a major set of patches pending which migrate our current setup to use async I/O (a bit like what I tried to do with SelectServer, but better). They support the current spawn and fork models too by some clever use of the the polling class.
The big thing they change though is the network plugins (dnsbl, rhsbl, check_early_talker). In order to work cleanly under async I/O we have to go through the async I/O layer that we are already using. This changes these plugins significantly (though the code works out simpler because a lot is abstracted elsewhere).
All of this will break Apache::Qpsmtpd. My plan is to look at making that work again later, since I think only one person has actually tried it I don't think that's a major loss.
You might be asking at this stage what the gains are? Well on our spamtrap I have (a version of) this code running which receives a constant stream of between 100 and 200KB of mail per second. That server copes with hundreds of concurrent connections, but I've seen it peak to thousands of concurrent connections. It's designed for high load but the benefit is that it copes nicely with lesser loads too. Basically it's an IronPort for the rest of us.
What I could do is check all this stuff in on a branch. However I always get the feeling that when you do that your code doesn't get exercised well, so I'd rather avoid that if possible.
It also merges all the different scripts into one server script, which auto-detects INETd/TcpServer mode by looking for ENV{REMOTE_HOST}, and takes a flag to switch to forkserver mode.
Should I just take the opportunity of the migration to SVN to just check this stuff in and we'll meld it into shape over the next few weeks, or should I check things in on a branch, or should I just keep them in my private repository until I feel I've got all the bases covered? Your comments appreciated.
Matt.
