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]

Reply via email to