Danny,
> sorry, thats the wrong way round its assmebly.xml that needs twiddled. > > However, applying the same SMTP test, this time 2000 1k mails from 20 > threads, Peter's changes resulted in more refused connections, 1st after > only 16 connections have been attempted and with no more at all after 361 > mails have been delivered. > > I haven't looked at the code really, but my empirical view is that SMTP > suffers from these changes. I've been running these tests all night with a slightly tweaked version of the patch I submitted (there was an erroneous notify() call in that patch). It runs fine under load, although there do seem to be some problems with the spooler if its put under consistent load. It's not clear what the relationship is to the handler changes. We've never driven the spooler under serious load, so we have no idea what load it can take. I'm looking into this. Might I suggest that you check your configuration. My first guess would be that you didn't correctly bump up the maximum number of threads in your server's thread pool. The specified number of 40 would be too low for your test, since 20 connections would consume 40 threads alone, not to mention that all the other blocks use at least one thread apiece. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
