Peter, Peter M. Goldstein wrote: > 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. >
Sounds good. > 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. :) > That is pretty compelling :) > 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 spent more than a few hours reading through the james-dev archives, but the earlier history of this problem somehow escaped me. I'm sorry if I seemed belligerant in pressing for more testing when the evidence was already quite clear. > > 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. > Good. Which is all the more reason for me to read and re-read the RFCs until then and spend a lot of time looking at those parts of the existing IMAP code (esp. the commands and test suite) which are not affected by the proposed changes. > --Peter > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -Nathan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
