Ok, didn't know what you were referring to and felt my JIRA comments
needed to be put in context.
I'd like to share one additional interesting observation:
from previous test runs it seem to me that memory is be more or less
constant if the number of unmatched mails at any given point in time has
an upper limit.
but in this situation here, the number of unmatched mails grows without
signs of convergence before the OOM exceptions are coming up.
If I am correct in saying that the sent but unmatched mails are those
sitting in the spool, it would be a goal to "make the spool more
scalable", whatever that means in the end...
Bernd
Stefano Bagnara wrote:
Bernd Fondermann wrote:
Stefano Bagnara wrote:
My patch should has nothing to do with db repositories. So I think
this doesn't matter.
[...]
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.)
Just to avoid misunderstandings my "it doesn't matter" was a reply to
Norman's "Before applied the patch of Stefano or after ?".
I completely agree with your analysis: we should close JAMES-512 and
eventually open a new bug with more information about the probable bug
you are describing now.
Imho it should be tested with more memory before opening a new bug. If
it is a leak it will happen even with Xmx set to 256 or 512MB, otherwise
maybe it is simply a requirement (maybe related to a bad usage of
memory, but if so it is less critical).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
