james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: svn commit: r470929 - in /james/server/branches/v2.3/src/java/org/apache/james: dnsserver/DNSServer.java nntpserver/NNTPHandler.java pop3server/POP3Handler.java remotemanager/RemoteManagerHandler.java smtpserver/SMTPHandler.java
Date Fri, 03 Nov 2006 19:37:08 GMT
Stefano Bagnara wrote:

> Noel J. Bergman wrote:
> > "Like" is not a technical justification.

> Agreed. In fact I added the technical justification.

What technical justification?  The static method?  What is the technical objection to the
use of the static method?  What problem does it create for this branch?  This is strictly
internal code with no supported altenatives.

> And I'm happy this is not a memory leak in james but an unbounded cache 
> in the JVM: the subject of the issue should be fixed for changelog purposes.

It is a bug in JAMES because we know that the problem exists in the class library, and missed
making that change.

>>> This patch introduce new hardcoded dependencies between components and 
>>> we worked hard to remove them everywhere.

>> So what?  It is the simplest fix.  The alternative is to backport the
>> more complex changes from trunk, but as Norman says, the full fix in
>> trunk is more complex than people wanted to backport.

> It is not true this is the simplest fix, unless you tried the system 
> property solution and proved it failed.

See below (again):

> > This is the same fix that is in trunk, except for the silly debate
> > over static vs assembly, and no one is proposing to keep this around
> > in future major releases.  We know that this fix works, and does not
> > have any side-effects.  Why would I want to use a un-bounded,
> > time-based, cache when everywhere else we use a bounded, properly
> > managed, DNS cache?  And why would I want BOTH?  This change is the
> > one that we have made everywhere else, and missed in these spots.

> my proposal is to add "-Dsun.net.inetaddr.ttl=10" or anything but "-1" 
> to the startup parameters.

See above, which you neglected.  Why would I want a false TTL of 10 seconds for all records,
including those that I want cached properly?  The solution is flawed, regardless of whether
it would address the memory leak.  Instead, we've consistently changed JAMES to use dnsjava
for all DNS resolution.

> Otherwise backport the full change from trunk.

Why, when everyone, including you, agrees that the change is more complicated?  What is the
technical justification for objecting to the static method?  No one else is complaining.

	--- Noel

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

View raw message