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
