RFR JDK-7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime (+more)

[Peter Levart]

Hi Bernd,

I noticed I haven't answered on two issues you exposed yet...

On 07/02/2014 12:58 AM, Bernd Eckenfels wrote:
>> >
>>> > >L732: I am unsure about the id field, isnt it enough to have the
>>> > >identity equality check for the replacement check and otherwise
>>> > >depend on equals()?
>> >
>> >The ConcurrentSkipListSet (based on ConcurrentSkipListMap) that is
>> >used as an ordered concurrent (but not blocking or locking) queue of
>> >items to be expired is not using hashCode/equals, but compareTo
>> >instead. So two instances of CachedAddresses must never compareTo
>> >each other as being "equal" if one wants to keep them all in the
>> >ConcurrentSkipListSet...
> Yes, I mean not using id in compareTo but idendity if (other==this)
> return 0; But maybe not worth it as you still need to order identical
> entries reliable (maybe by system hash).

Yes, if two CachedAddresses objects: ca1, ca2 have same expiryTime and 
c1 != c2, compareTo still has to be a total order for 
ConcurrentSkipListSet to function properly. System.identityHashCode() 
can theoretically return the same value for two different objects.

>
>>> > >BTW1: might be the wrong RFR, but considering your good performance
>>> > >numbers for an active cache, would having 100ms or similiar default
>>> > >negative cache time make sense without impacting (visible) the
>>> > >semantic.
>> >
>> >It depends on the "application". If some app is doing more than 10
>> >look-ups of same non-existent hostname per second, it will have
>> >effect. Otherwise not. It seems that negative answers are not so
>> >frequent in practice that default policy would require caching them.
>> >One can always choose the policy manually.
> Actually I think an application who retries lookups without rate limit
> might not be too uncommon as they typically fail only after timeouts.
> However if you have for example a dropped default route nameserver
> answer can return the error immediatelly and you get into a busy loop.

With negative caching turned on, such loop will be even more busy. It 
won't make a load on name service, that's true, but it would consume 
even more CPU time locally. The catch is that default policy can be 
overridden on a per-app (JVM) basis with a system property. Changing 
default policy of negative caching is not something I'm trying to do 
with this patch. It could be done as a separate issue if desired.

Regards, Peter

> But yes most likely most apps only try it a small time.
>
> Gruss
> Bernd