Re: about JDK-8186628

2018-04-21 Thread Peter 

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





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 >:


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

[2]
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

Re: about JDK-8186628

2018-04-21 Thread Peter Levart 

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





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 >:


    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
    
    [2]
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

Re: about JDK-8186628

2018-04-21 Thread Peter 
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.

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





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 >:


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

[2]

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

Re: about JDK-8186628

2018-04-20 Thread Ivan Gerasimov 
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





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 >:


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

[2]

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

Re: about JDK-8186628

2018-04-20 Thread nezih yigitbasi 
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 :

> 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
> [2] 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
>
>

Re: about JDK-8186628

2018-04-20 Thread Ivan Gerasimov 

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
[2] 
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