On 07/02/2014 12:58 AM, Bernd Eckenfels wrote:
Hello,
Am Wed, 02 Jul 2014 00:45:01 +0200
schrieb Peter Levart :
L782: is it better to use putIfAbsent unconditionally, instead of
get/putIfAbsent in NameServicdeAddr?
I want to keep the semantics of original code that guarantees that
there will o
Hello,
Am Wed, 02 Jul 2014 00:45:01 +0200
schrieb Peter Levart :
> > L782: is it better to use putIfAbsent unconditionally, instead of
> > get/putIfAbsent in NameServicdeAddr?
>
> I want to keep the semantics of original code that guarantees that
> there will only be a single look-up to the name
Hi Bernd,
Thanks for reviewing.
On 07/01/2014 10:06 PM, Bernd Eckenfels wrote:
Looks good, like it, Peter.
some nits: instead of adding createTime and cacheNanos, only have a
expireAfter?
I could, yes. I just have to be careful not co compare two expireAfter
values with '<' or '>'.
The ja
Looks good, like it, Peter.
some nits: instead of adding createTime and cacheNanos, only have a
expireAfter?
L782: is it better to use putIfAbsent unconditionally, instead of
get/putIfAbsent in NameServicdeAddr?
L732: I am unsure about the id field, isnt it enough to have the
identity equality
I haven't looked at the patch, but generally ... all uses of
currentTimeMillis to measure elapsed time should be migrated to use
difference of two nanoTime values, and such a change should be done
independently of other changes.
IIRC lookup.sh is a known flaky test being fixed elsewhere.
On Tue,
Hi,
I propose a patch for this issue:
https://bugs.openjdk.java.net/browse/JDK-7186258
The motivation to re-design caching of InetAddress-es was not this issue
though, but a desire to attack synchronization bottlenecks in methods
like URL.equals and URL.hashCode which use host name to IP addr
