Noel J. Bergman wrote:
Noel J. Bergman wrote:
Stefano Bagnara wrote:
What does the "Confirmed" word in the subject means?
As noted in the subject: confirmed but *unidentified.*
What mysql drivers do you use? What mysql server do you use?
As mentioned in the e-mail, org.gjt.mm.mysql.Driver. Which, by the way, is
what MySQL recommended as a workaround for people having problems with
memory leaks in Connector/J.
The fact is that every connector/j (even 5.0.0beta) contains the
org.gjt.mm.mysql.Driver class that points to the new
com.mysql.jdbc.Driver. That's why I ask...
Where did you read that mysql recommend to downgrade to 2.0.14 as a
workaround for memory leaks?
The process grew slowly for a week until it blew up.
Let me rephrase that: as I had said in the original post, it was really
quite stable for the better part of a week, just as my current process has
been really stable at 113MB since Monday. I was pretty pleased and
confident. But then last weekend, the "JVM process size [grew] from a
stable 114MB to 130MB" by Sunday night, and died early Monday morning after
10 days or so over non-stop operation. And the OOM condition persisted, so
it wasn't a transient failure due to a single large message.
Any idea about what could have been changed from monday to sunday? This
would indicate that the leak is not on common code but in operations
that have been only called in the latest days..
About the single large message statement, I agree, but we should keep in
mind that this is not so obvious: maybe we now have a problem in the
recovery code and that we don't restore correctly from an OOM due to a
large message (as an example). Now you say that you have a very low
limit on the message size so we could exclude it.
So the real question appears to be what infrequent event would cause such a
leak to occur. And can I repeat it. :-\ And if not, then what?
--- Noel
If you weren't a james developer I would ignore this message until you
provide more informations (config.xml, custom mailets, versions for
every component) ;-) ...
Btw we can't keep our rc release process blocked forever, so either we
can confirm this or we should release the final. So please provide as
much infos as you can as soon as possible.
As a last note, if we won't release 2.3.0 final before august 31st we'll
have to update the source headers and I think it is better to make a new
rc after such change (even if it changes only comments).
So we have to choose either to start a vote for 2.3.0 final today or to
start applying the license header changes and prepare a 2.3.0rc3 while
you try to identify the problem or give us the opportunity to help in this.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
