Nathan,
> 1) This thread is quite interesting because I've asked many of these > same questions in beginning to look at the IMAP stuff, which in many > cases (at least the listener and handler code) seems to be based on old > versions of the POP equivalents (i.e., they are missing august and > september changes by danny and peter to the POP code). Yep. Same issues apply. For the most part, these are overarching architecture issues. If and when this patch is applied, it would make sense for the IMAP server class to extend AbstractJamesService (which would give it enabled/disabled, thread group control, all the code for starting a server socket and delegating to a ConnectionManager, etc.). And for the IMAPHandler to be suitably simplified so it concerns itself solely with IMAP protocol issues. One of the most abstract, but fairly compelling, reasons for the patch I've proposed is that it makes rolling out new services fairly easy. The person rolling out the new service basically needs to understand the Avalon Configuration object, and then they can go to town. The current code base would require them to either understand the whole of the Server classes or to cut and paste them. The latter is especially likely to induce errors (as the one which seems to have existed since the beginning of the NNTP server project which disabled SSL). > 2) In your initial post, you mention doing some "basic" and "load" > testing to further quantify the memory/robustness/scalability issues and > show how your patch solves them. What about (and I'd be happy to donate > time for this): > > a)using a profiling tool to see how much time is actually being > wasted by configuring each Handler instead of more tightly coupling them > to the server listener. This would be fine, although as I've emphasized in my other posts, this is more a fundamental architecture problem than a performance problem. There are issues with configuration, logging, and division of responsibility. I'd be happy to see the performance numbers, especially when graphed against load. Since we know the scheduler crashed the system under even moderate load, it's pretty clear that no one to date could've collected statistics on performance under heavy load. And that's where changes like this one have their highest performance impact. > b)Do you have before/after metrics for your load tests? A 2X > improvement will be a strong argument in itself. JMeter doesn't seem to > support email server load testing - is there anything better than this > (e.g. PushToTest, > http://www.etestinglabs.com/benchmarks/svrtools/email/t1intro.asp)? Before - crashed. After - didn't crash. :) There's been a recent discussion of this on the James users list, as well as much earlier discussion by Andrei Ivanov. The crash/not crash scenario, which is obviously the dominant effect, is due to the Scheduler->Watchdog change. I haven't I've been writing some of my own test scripts - nothing fancy, just simple Java programs that push at the server. > Again, I'd be more than happy to help in testing because this > significantly affects what I'm doing in IMAP, and I'm going to have to > perform this kind of testing on IMAP due to its complexity and higher > overhead. It certainly does. Once we get things stabilized for 2.1, I was intending to port over the code changes to the IMAP proposal. As I mentioned in my reply to Sascha a couple of weeks ago, merge of the 2.1 release into the IMAP code is (IMHO) a necessary precondition for moving the IMAP code. I would be very happy to participate in that effort. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
