This sounds suspiciously like it could be related to the extra file (unpaired) hanging around in the file repository implementation... would be great if that albatross could be solved finally as well.
--
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
Peter M. Goldstein wrote:
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>
-- To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
