Stefano Bagnara wrote: > The File_Persistent_Stream_Repository currently caches every > inputstream and outputstream used and never release them.
Correct. It assumes that messages are released by the client code calling the remove operation on the respository. AFAICS, the code is holding on to the streams in order to ensure that all streams are closed so that the file can be deleted by the remove(key) method. > Maybe it is safe to comment the m_inputs and m_outputs hashmaps in the > File_Persistent_Stream_Repository Possibly. We should also add code to better handle the RuntimeException (as we rewrite things, we really should clean up that usage) that will be thrown if we try to delete a meessage on which some code had left a stream open. Hopefully, we're good about closing. > File_Persistent_Stream_Repository has been copied by the > cornerstone-store project. IIRC, amusingly, they told us to copy/fork the code, because they were going to delete it from Cornerstone. > Even if I think this is a bug I'm surprised that this throw an OOM even > in the current James 2.3 branch code and trunk If test cases and real-world usage delete messages, which is normal practice, this problem is never surfaced. It is only a problem when you leave messages in the repositorty, e.g., a dead-letter drop, which is the case I was working on before, but I missed this part, and ran out of time to dig. I'll look at it more closely after I land. Currently on approach into Chicago. > inbox repositories are kept in a ReferenceMap (soft values) so > the whole "leak" should only be referenced via a weak reference Are we sure that nothing else is holding a hard reference, e.g., the RepositoryManager? :-) > this would be anyway a problem with the SpoolRepository. No, I don't believe so. The messages would be removed from the spool, and thus the spool would not exhibit this problem. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]