Noel J. Bergman wrote:
Norman Maurer wrote:
So far, I have a working hypothesis
After 12 hours or so, InetAddress cache related objects appear to be in
excess of 20% of heap usage, and increasing.
It appears to be a single line in the SMTP handler that was changed
in trunk, but not backported.
2.3.0: remoteHost = socket.getInetAddress().getHostName();
trunk: remoteHost = dnsServer.getHostName(socket.getInetAddress());
The Problem is that we need "many" changes to backport this.
It isn't so bad if you use a static method instead of worrying over
assembly. :-)
I prefer a big patch instead of a static method introducing an hard
dependency between components that should not have common knowledge.
And we agreed that we ony want to backport "critical" stuff.
Fixing memory leaks is critical. :-D
--- Noel
I still don't understand why we don't experience this leak.
If I understood your latest messages the memory leak is not in james
code, but in the jvm: is it possible that the bug is only present in
your jvm release?
Maybe that this should be considered critical to Sun JRE and solved with
"upgrade your jvm" on the James side: we should of course confirm this,
before.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
