Stefano Bagnara wrote:
My patch should has nothing to do with db repositories. So I think this
doesn't matter.
quick recap of my conclusions around JAMES-512:
a specific problem with file-repos was reported and your fix was applied.
after the fix, the problem symptoms (OOMs) don't completely go away,
they only come appearant later.
so, the fix seems to help, but presumably doesn't make the problem go
away. (another possibility is, that it's a completely different problem
with similar symptoms.)
at this time, the question should be posed: is it still only a file-repo
problem, or a more general problem?
that's the whole point of comparing file-repo with non-file-repo under
the same conditions and the result is: db-repo has similar
problems/symptoms. (and that's why it matters to repeat the tests with
db repos.)
knowing this, JAMES-512 could be closed because it reports only a very
specific memory leak.
next, we could open a new JIRA or could conclude that handling 500
mails/min really needs more memory than 64MB.
Instead I would like to know wether this is derby or mysql or anything
else?
I know many connector/j uses big buffers and maybe they also have leak
problems. Derby instead have big caches, maybe it is a leak or maybe we
simply have to tune derby parameters (like we already did)
I used default derby.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
