Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of t.p.ellison@gmail.com
 designates 64.233.182.191 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=b3BWJGKWxfqsol+cR0Bx5GnkHhSxlyF0KAbTqf6G0Noybquf8ELyTaJtAhHRyGmHROVcJnnxY5iLDNr8a09ak1ag8aycgIA4pAMOAyY3A/0iegMoft0PLEn53tE8rAoGRQplQ1yO2QlBD8FLevebIkInztuYrju1RQuxX8yxUI8=
Message-ID: <48104BFF.5010407@gmail.com>
Date: Thu, 24 Apr 2008 09:59:43 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [classlib][luni] put only host name in UnknownHostException
References: <3b3f27c60804232023w4402e18djfb43e0c72b7a9e63@mail.gmail.com>
In-Reply-To: <3b3f27c60804232023w4402e18djfb43e0c72b7a9e63@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Nathan Beyer wrote:
> https://issues.apache.org/jira/browse/HARMONY-5784
> 
> Anyone have any issue with making this change? Currently, the behavior is
> such that the host is in the message, but with the additional "No such file
> or directory" message. There doesn't seem to be much value in the additional
> message, so changing this to just be the host that was passed in is pretty
> trivial.

Yeah, can dump the bogus information from the message.

> However, when unwinding this a bit, there's this NegativeCache class that
> stores failed lookups and the message failure. Is this really needed? Is it
> appropriate? There's already a cache of resolved InetAddress object that
> were found, but this cache has a expiry, as I would have expected, but the
> NegativeCache doesn't. Any thoughts or comments on eliminating this negative
> cache bit? It seems like the negative cache isn't being maintained properly
> (no expiry, etc), so if a host became accessible over time, it wouldn't be
> accessible. Additionally, I don't think the overhead of the memory, though
> minimal, is really worth not executing a lookup, which would already be
> offset by resolvable hosts in the other cache.

The negative cache is needed, and it is described by the spec for 
InetAddress [1] (see "InetAddress Caching").

It should have an expiry mechanism which admins can tweak using the 
networkaddress.cache.negative.ttl property.

[1] http://java.sun.com/j2se/1.5.0/docs/api/java/net/InetAddress.html

Regards,
Tim