----- Original Message ----- From: "Peter M. Goldstein" <[EMAIL PROTECTED]> > > 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.
Very good stuff. :-) Trully awesome. > > 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. I have always wondered about avalon folks creating threading library. I wonder why they didn't use Doug Lea's util concurrent. At one point there was talk using it and but not sure why they invented their own. Harmeet -- To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
