Stefano Bagnara wrote:
> Noel J. Bergman wrote:
>>> A third, alternative, workaround is to add:
>>> java.security.Security.setProperty("networkaddress.cache.ttl" , "10");
>>> somewhere in our code.
>> <<sigh>> Except that it addresses none of the other technical flaws with
>> using Sun's code. If you think that this is such a good idea, why don't
>> we do it throughout the trunk code, too?
> You are right, we probably should add this also to trunk.
OK, so you propose that we should remove dnsjava, except for resolving MX
records, and use InetAddress with the above change? Of course not, since ...
> in trunk we already optimized the use of the caches and their expiration
> by moving to dnsjava (even if this still needs some tuning because it
> currenlty use a mix of static and standard calls)
Yes, that is exactly the same thing I am trying to do in the 4 lines of code
that we missed in v2.3.0, and having you block making that change because you
don't like the static method.
> but it could happen (or maybe it already happen) that some third party
> library we use still make use of InetAddress "flawed" methods, and the
> above property would save us from the possible OutOfMemory because of
> the unbounded cache.
Perhaps, but I would rather vet the code, and be more careful about what we
use. Now that we know one of the things to look for carefully, we can avoid
it. The better solution is to avoid the problem, not mask it.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
