<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="background-color: rgb(255, 255, 255); color: rgb(0, 0,
0);" text="#000000" bgcolor="#FFFFFF">
Hi Peter,<br>
<br>
<div class="moz-cite-prefix">On 04/21/18 10:42, Peter wrote:<br>
</div>
<blockquote type="cite" cite="mid:5ADAF95D.7080802@zeus.net.au"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900; padding: 0px 15px; margin: 2px 0px;"><![endif]-->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.
<br>
<br>
It was non blocking if the underlying collection was, although it
hasn't been updated to Java 8.
<br>
<br>
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.
<br>
<br>
Regards,
<br>
<br>
Peter.
<br>
<!--[if !IE]></DIV><![endif]--></blockquote>
<br>
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.<br>
<br>
Regards, Peter<br>
<br>
<blockquote type="cite" cite="mid:5ADAF95D.7080802@zeus.net.au"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900; padding: 0px 15px; margin: 2px 0px;"><![endif]-->
<br>
On 21/04/2018 3:45 AM, Ivan Gerasimov wrote:
<br>
<blockquote type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900; padding: 0px 15px; margin: 2px 0px;"><![endif]-->
<br>
I'll go ahead with a review of the enhancement request
JDK-8202086 shortly on this list.
<br>
<br>
And we'll still need to decide what has to be done in the
earlier releases of JDK.
<br>
<br>
With kind regards,
<br>
<br>
Ivan
<br>
<br>
<br>
<a class="moz-txt-link-rfc2396E" href="https://bugs.openjdk.java.net/browse/JDK-8202086"><https://bugs.openjdk.java.net/browse/JDK-8202086></a>
<br>
<br>
<br>
On 4/20/18 10:06 AM, nezih yigitbasi wrote:
<br>
<blockquote type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900; padding: 0px 15px; margin: 2px 0px;"><![endif]-->Ivan,
thanks for the information. Any ideas about when one of these
solutions can be released?
<br>
<br>
Nezih
<br>
<br>
2018-04-20 9:22 GMT-07:00 Ivan Gerasimov
<<a class="moz-txt-link-abbreviated" href="mailto:ivan.gerasimov@oracle.com">ivan.gerasimov@oracle.com</a>
<a class="moz-txt-link-rfc2396E" href="mailto:ivan.gerasimov@oracle.com"><mailto:ivan.gerasimov@oracle.com></a>>:
<br>
<br>
Hello Nezih!
<br>
<br>
This issue is still being discussed off-list.
<br>
There have been two approaches proposed so far: 1)
improve the
<br>
session cache and 2) provide an option to turn the cache
off
<br>
completely.
<br>
<br>
The former one is good by itself, so I filed an
enhancement
<br>
request [1] with a link to proposal made by Peter Levart
[2].
<br>
However, as this is an enhancement, it seems unlikely it's
going
<br>
to be backported to earlier releases of JDK.
<br>
<br>
With kind regards,
<br>
Ivan
<br>
<br>
[1] <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8202086">https://bugs.openjdk.java.net/browse/JDK-8202086</a>
<br>
<a class="moz-txt-link-rfc2396E" href="https://bugs.openjdk.java.net/browse/JDK-8202086"><https://bugs.openjdk.java.net/browse/JDK-8202086></a>
<br>
[2]
<br>
<a class="moz-txt-link-freetext" href="http://mail.openjdk.java.net/pipermail/security-dev/2017-November/016512.html">http://mail.openjdk.java.net/pipermail/security-dev/2017-November/016512.html</a><br>
<a class="moz-txt-link-rfc2396E" href="http://mail.openjdk.java.net/pipermail/security-dev/2017-November/016512.html"><http://mail.openjdk.java.net/pipermail/security-dev/2017-November/016512.html></a><br>
<br>
<br>
On 4/18/18 9:32 PM, nezih yigitbasi wrote:
<br>
<blockquote type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900; padding: 0px 15px; margin: 2px 0px;"><![endif]-->
Hi,
<br>
We are hitting the scalability problem of the SSL
session cache
<br>
in production that JDK-8186628 is addressing.
<br>
I see that JDK-8186628 has not been updated since
Nov'17, so I
<br>
just wanted to get information about what the current
plans are
<br>
regarding that issue.
<br>
<br>
Thanks,
<br>
Nezih
<br>
<!--[if !IE]></DIV><![endif]--></blockquote>
<br>
-- With kind regards,
<br>
Ivan Gerasimov
<br>
<br>
<br>
<!--[if !IE]></DIV><![endif]--></blockquote>
<br>
-- <br>
With kind regards,
<br>
Ivan Gerasimov
<br>
<!--[if !IE]></DIV><![endif]--></blockquote>
<br>
<!--[if !IE]></DIV><![endif]--></blockquote>
<br>
</body>
</html>