Noel J. Bergman wrote:
Stefano Bagnara wrote:
Currently I cast my veto on this change (I also wrote I didn't like this
change in a previous message).
"Like" is not a technical justification. I don't like Maven (which actually
HAS issues, unlike this change). And I don't like memory leaks, even ones that I am told
should be closed without being fixed because they are a figment of my imagination.
Agreed. In fact I added the technical justification.
And I don't like it because of technical justifications.
What is the relation of this issue with Maven?
And yes, you don't like maven and in fact james still builds with ant:
I'm sure that If I start a vote to update our james build to maven you
will veto it, so I really don't get your reference to the maven issue.
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.
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. If we were going to keep development
v2.3 extensively, I'd agree on backporting the more complex changes from trunk,
but this is a dead-end fix that addresses the problem in exactly the same
manner.
It is not true this is the simplest fix, unless you tried the system
property solution and proved it failed.
Have you tested the solution using the system property or the security
property? I think we should fix it using that solution.
Why? 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.
So I see two choices: we keep it or we backport the more complex code from
trunk.
--- Noel
my proposal is to add "-Dsun.net.inetaddr.ttl=10" or anything but "-1"
to the startup parameters.
Otherwise backport the full change from trunk.
The first is the "least change" workaround, the last is the most correct.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
