All, Ok folks, we've found the big non-scheduler memory leak. The source can be found in the MimeMessageInputStreamSource. The use of the deleteOnExit() method either caused a JVM internal list to grow without bound or prevented cleanup of the temporary file objects. Whatever the exact details, it's clear that this is the source of the problem. The dependence on the finalizer method for file cleanup is another severe problem in this class. Removing the deleteOnExit and adding an explicit dispose() chain to force deletion of the file resolves this memory issue.
In the process of resolving this, we discovered a serious bug in the Avalon Excalibur DefaultPool and DefaultThreadPool implementations. Basically, if an interrupted thread attempts to return an object to the pool, it corrupts the mutex of the pool and causes an eventual catastrophic failure. This issue is currently under discussion on the Avalon-dev list. Noel and I have been running tests and revamping code for much of the last two or three days. As of today, we've got a code base that runs consistently with 20 connections, 2 messages per connection, 1k messages, at a rate of ~3000 messages per minute. Heap size remains stable at about 4.5 MB. Total thread count is stable at 112 threads. This is on a PII 400MHz Celeron Linux box. We had some issues that resulted from the above Avalon Excalibur bugs, but we think we've got a relatively bullet proof version of the code. We're running a test now (Noel is gone for the next four hours, but the test is running in his absence) but the first 30 minutes of testing showed no triggering of the Avalon Excalibur problem. Previous runs (before bulletproofing) resulted in an error within the first 15 minutes and a unresponsive server within 1.5 hours. Once we've got a successful test, and we've taken a little time to neaten up the code, we'll be ready to post the diffs. I suspect we'll reach that point sometime tomorrow, assuming all goes well with the latest tests. --Peter -- To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
