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.
> 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?
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.
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
