james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Confirmed but unidentified memory leak in RC2
Date Fri, 03 Nov 2006 15:05:06 GMT
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 

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 

> 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.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message