Hi Peter,
On 04/21/18 10:42, Peter wrote:
I wrote caching software that decorated any Java collection with soft,
weak, timed or strong references, it utilised a background thread to
clean references from underlying collections.
It was non blocking if the underlying collection was, although it
hasn't been updated to Java 8.
Regarding patch comments, I don't mean to sound rude, but I don't
think there's such a thing as a harmless data race.
Regards,
Peter.
Perhaps harmless is not the right expression, but in this case, I think
the data race(s) can do no "harm" to the correct / intended execution of
program logic. That's my current belief, but you can prove me wrong if
you want ;-) The data race is between CacheEntry.[getKey, getValue] and
CacheIntry.invalidate that resets both key & value to null. When a
CacheEntry is published, it is published without data race, with key &
value being non-null. CacheEntry is private class, used only in
MemoryCache, so it is never exposed to user code. User code only sees
the result(s) of reading CacheEntry.[getKey, getValue] (returned from
Cache.get(key) and from Cache.getCachedEntries()). The former allows
null returns that logically mean an absence of value while the later
constructs a map of live entries that are or were present in the cache
at the time of invocation, filtering out null key(s)/value(s). The
guarantees of those two methods are enough for correct functioning of
user code (the SSL implementation), and this is what I called "harmless"
data race because technically it is a data race.
Regards, Peter
On 21/04/2018 3:45 AM, Ivan Gerasimov wrote:
I'll go ahead with a review of the enhancement request JDK-8202086
shortly on this list.
And we'll still need to decide what has to be done in the earlier
releases of JDK.
With kind regards,
Ivan
<https://bugs.openjdk.java.net/browse/JDK-8202086>
On 4/20/18 10:06 AM, nezih yigitbasi wrote:
Ivan, thanks for the information. Any ideas about when one of these
solutions can be released?
Nezih
2018-04-20 9:22 GMT-07:00 Ivan Gerasimov <ivan.gerasi...@oracle.com
<mailto:ivan.gerasi...@oracle.com>>:
Hello Nezih!
This issue is still being discussed off-list.
There have been two approaches proposed so far: 1) improve the
session cache and 2) provide an option to turn the cache off
completely.
The former one is good by itself, so I filed an enhancement
request [1] with a link to proposal made by Peter Levart [2].
However, as this is an enhancement, it seems unlikely it's going
to be backported to earlier releases of JDK.
With kind regards,
Ivan
[1] https://bugs.openjdk.java.net/browse/JDK-8202086
<https://bugs.openjdk.java.net/browse/JDK-8202086>
[2]
http://mail.openjdk.java.net/pipermail/security-dev/2017-November/016512.html
<http://mail.openjdk.java.net/pipermail/security-dev/2017-November/016512.html>
On 4/18/18 9:32 PM, nezih yigitbasi wrote:
Hi,
We are hitting the scalability problem of the SSL session cache
in production that JDK-8186628 is addressing.
I see that JDK-8186628 has not been updated since Nov'17, so I
just wanted to get information about what the current plans are
regarding that issue.
Thanks,
Nezih
-- With kind regards,
Ivan Gerasimov
--
With kind regards,
Ivan Gerasimov
