Thanks for your explanation.
I worked on a lot of early java code circa Java 1.2 - 1.4, converting it
to the post Java 5 memory model. Latent race conditions caused
hundreds of bugs, and problems would occur in other unrelated parts of
the code, it was very brittle, any changes to code would result in
inexplicable test failures elsewhere. In the end I eliminated every
race condition I found, harmless or otherwise, using both visual
inspection and static analysis, the code lost it's brittle nature and
became much easier to maintain since.
Regards,
Peter.
On 21/04/2018 7:51 PM, Peter Levart wrote:
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
