Noel J. Bergman wrote:
Stefano Bagnara wrote:
Noel J. Bergman wrote:
Norman Maurer wrote:
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.
Feel free to adjust it, but this is the principle of least change for
maintenance work. Trunk has the "big patch". And they still have common
knowledge anyway. We have only decoupled our own interface from our own
implementation. And that's non-critical for our internal code.
Well, let's collect some proof that the jvm problem is correctly
workarounded this way, then we'll decide how to fix it. At this time I
think it should be better to add the system property to alter the
default behaviour of InetAddress and do not change the code (for the 2.3
branch).
I don't think we'll want to release 2.3.1 in a week with this patch: is
this right?
I still don't understand why we don't experience this leak.
Are you running trunk or v2.3.0? How many connections per day? Have you
set anything in the environment that isn't part of the standard JAMES
distribution?
2.3.0 everywhere. Somewhere "my patched version", somewhere clean 2.3.0.
As soon as we'll branch I'll start upgrading some of them to next-major
branch.
I receive roughly the same number of connections as the ASF, the vast
majority from DHCP pools, courtesy of Microsoft and ISPs that neglect to
force port 25 to their own SMTP gateways out of laziness or their own
inability to keep up with the mail volume of the MS-Windows Worm.
The server that receive most connections receives around 100K mails/day,
not so much, but I never noticed memory problems: btw maybe that the
client addressese are often the same in my environment.
"roughly the same number of connections as the ASF" is a little
meaningless for people not having access to the logs of ASF mailservers
;-) : can you give us numbers?
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?
No. This is a long standing defect in InetAddress, and can be seen in the
class' source code. The right fix is to never use InetAddress to resolve
anything. A workaround is to force the cache to timeout with Sun-specific
environment variables.
--- Noel
In java 1.5 the "standard" property (networkaddress.cache.ttl) works: I
have not checked with java 1.4.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
