Peter, The class TimeoutWatchdogFactory is missing from this list.
Regards Steve > -----Original Message----- > From: Peter M. Goldstein [mailto:peter_m_goldstein@;yahoo.com] > Sent: Saturday, October 19, 2002 2:01 PM > To: 'James Developers List' > Subject: Latest diffs, source code > > > > All, > > Attached is a set of source files and diffs that should allow > you to reproduce the code base that Noel and I have been > using for our latest testing. > > The test ran for over seven hours, with a rate that started > close to ~3000 messages/minute and stabilized at ~2500 > messages/minute. We don't have a good explanation for this > change, but the system was under a great deal of stress > (logging, TCP/IP, etc.) that may have accounted for the > eventual degradation. > > Total number of threads was stable at 112 for the first hour > or two, but grew to 162 threads after that and stabilized. > Analysis of the logs (~750 MB of them) confirmed that there > was no thread leak (all worker threads were reused as > expected over the course of the test run). My suspicion is > that the growth in the thread pool size was a result of a > thread scheduler statistical anomaly (disposed but not exited > connection handler/watchdog threads) and is not an actual > cause for concern. Unfortunately this is difficult to confirm > or refute, but it matches the observed behavior. > > Java heap size grew slowly over the course of the test, from > about 4.5 MB to about 5MB. We don't see this as a real cause > for concern, considering the number of open resources, etc. > that the product was managing. > > The code executing threads from the thread pool is now > appropriately wrapped in try/catch/finally blocks that ensure > that a temporarily empty thread pool does not constitute a > fatal error. If a thread is unavailable, the connection will > simply be refused. Obviously, if the thread pool is too > small (i.e. no threads available at any time to service > connections), then this will result in an unresponsive > server. But the current configuration has proved to be more > than adequate for our test. > > Noel ended the test when he saw a notable performance > degradation (drop to <1000 messages/minute). He later > discovered that some other work was being done on the same > server at that time that very well may have been responsible > for the drop in performance. So we don't actually know what > caused this issue and it may not actually be an issue at all. > If Noel and I can find the time we will attempt to run > another test to get info on this one way or another. > > So here's the summary: > > i) James' SMTP handler can process 2500-3000 messages/minute > consistently on a PII 400 MHz Celeron running Linux > > ii) In the source of seven hours, over 1,000,000 messages > were pushed through the James SMTP service. > > iii) There was no sign of the catastrophic memory leaks that > plagued earlier versions of James. > > iv) There may be some outstanding "glitches" but they are > orders of magnitude less severe than the previous issues. > > --Peter > > > > -- To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
