This is somewhat amusing (in a self-deprecating way), and I thought would be interesting to the list as well. I had about 800 emails queued in a mail repository (in a database) that were for a former employee. I finally got his new address this morning, and so stuck those 800 emails back in the "incoming" repository with his old address now aliased to his new address. Normally I leave spoolmanagerthreads configured at 1 (I had forgotten why). To speed delivery, I had the bright idea to change it to 5 threads. (note, I have it configured for 8 delivery threads, and I believe that is actually per spool manager, given the way it works, so 40 delivery threads). The bug (and funny part) is that James delivered 1 copy of each message PER SPOOL MANAGER THREAD. So instead of 800 emails, it sent 4000. The good news, and throughput report is that James, using a database on another machine, delivering to a remote server across the Internet, and rarely going over 30% CPU usage (on a PIII 400), sent these 4,000 emails in 13 minutes. Regular incoming/outgoing messages were still flowing, and a few pop3 connections were open. This was with the 1.2rc1 release, so it was parsing and instantiating the message half a dozen times during processing, and was using Town still which also isn't efficient. I expect to have significantly higher throughput with the new release, but just wanted to share some positive results on James' throughput in a real world setting. Serge Knystautas Loki Technologies http://www.lokitech.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
