Code Review Request, JDK-8213577, Update the default SSL session cache size to 20480
Xue-Lei Fan
xuelei.fan at oracle.com
Mon Nov 26 18:14:30 UTC 2018
I made the update accordingly:
http://cr.openjdk.java.net/~xuelei/8210985/webrev.04/
Thanks,
Xuelei
On 11/19/2018 7:39 AM, Sean Mullan wrote:
> On 11/16/18 3:19 PM, Xuelei Fan wrote:
>> Thanks for the review, Jmail & Sean.
>>
>> New webrev:
>> http://cr.openjdk.java.net/~xuelei/8210985/webrev.03/
>>
>> I will update CSR when we come to an agreement.
>>
>> On 11/16/2018 11:33 AM, Sean Mullan wrote:
>>> 122 * @apiNote Both the session timeout and cache size impact
>>> performance
>>> 123 * of future connections. It is not recommended
>>> to use too big
>>> 124 * or too small timeout or cache size limit.
>>> Applications should
>>> 125 * carefully weigh the limits and performance for
>>> the specific
>>> 126 * circumstances.
>>>
>>> I am not really sure if the @apiNote is that useful or appropriate,
>> I worry about the default value actually.
>
> Then maybe the default is what you should be discussing in this
> apiNote. Right now I don't think the apiNote adds much. To me, all you
> are really saying is that these are methods that can be used to tune
> performance, which I think should be obvious from their name and
> description. Maybe the apiNote should say something like:
>
> "Note that the JDK Implementation uses default values for both the
> session cache size and timeout. See getSessionCacheSize and
> getSessionTimeout for more information. Applications should consider
> their performance requirements and override the defaults if necessary."
>
> Also I think you should add a similar @implNote for getSessionTimeout
> which describes the default value (86400 seconds or 24 hours), ex:
>
> @implNote The JDK implementation returns the session timeout as set by
> the {@code setSessionTimeout} method, or if not set, a default
> value of 86400 seconds (24 hours).
>
>> A new bug may be filed again and argue if the default value is not
>> a proper one. The default value of session timeout and cache size
>> really depends on the real world circumstances. I think we'd better
>> make a clarification in the spec, and remind application tune them
>> accordingly.
>
> Ok, but the apiNote above says nothing about the default value.
>
> --Sean
>
>>
>>> but it seems a bit odd to talk about the session timeout in this
>>> method.
>> The performance impact is a combination of the session timeout limit
>> and cache size. I would like application consider them together if
>> need to tune the values, but not individually.
>>
>>> If you still want to add this, I would add an @apiNote to each of
>>> the setSessionCacheSize and setSessionTimeout methods and just
>>> discuss each property separately.
>>>
>> I added the update spec to both setSessionCacheSize and
>> setSessionTimeout.
>>
>>> Also, unless you say what "too big" or "too small" is, I would avoid
>>> giving this advice.
>>>
>> It makes sense to me.
>>
>> Thanks,
>> Xuelei
>>
>>> --Sean
>>>
>>>
>>> On 11/16/18 1:30 PM, Xuelei Fan wrote:
>>>> It's time to use the systemProperty tag as it is ready.
>>>>
>>>> As we are already there, I also update the setSessionCacheSize()
>>>> for more clarification.
>>>>
>>>> Please review both CSR and webrev:
>>>> https://bugs.openjdk.java.net/browse/JDK-8213577
>>>> http://cr.openjdk.java.net/~xuelei/8210985/webrev.02/
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>> On 11/16/2018 8:19 AM, Sean Mullan wrote:
>>>>> On 11/15/18 3:37 PM, Xuelei Fan wrote:
>>>>>> Hi Sean,
>>>>>>
>>>>>> Are you OK if we do it later? I'm waiting for the
>>>>>> @systemProperty tag, proposed within JDK-5076751. I will file a
>>>>>> bug to use the tag for more cleanup.
>>>>>
>>>>> JDK-5076751 is completed and pushed to JDK 12, so you can use the
>>>>> new tag now.
>>>>>
>>>>> I think it would be easier to do it now, it seems pretty simple
>>>>> and that way there is no need to worry about it later.
>>>>>
>>>>> --Sean
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Xuelei
>>>>>>
>>>>>> On 11/15/2018 11:55 AM, Sean Mullan wrote:
>>>>>>> This is a good opportunity to document the
>>>>>>> javax.net.ssl.sessionCacheSize system property in the
>>>>>>> SSLSessionContext API (and use the new @systemProperty tag) in
>>>>>>> an @implNote, for example:
>>>>>>>
>>>>>>> /**
>>>>>>> * Returns the size of the cache used for storing
>>>>>>> * <code>SSLSession</code> objects grouped under this
>>>>>>> * <code>SSLSessionContext</code>.
>>>>>>> *
>>>>>>> * @implNote The JDK implementation returns the cache size
>>>>>>> as set by
>>>>>>> * the {@code setSessionCacheSize method}, or if not set,
>>>>>>> the value
>>>>>>> * of the {@systemProperty javax.net.ssl.sessionCacheSize}
>>>>>>> system
>>>>>>> * property. If neither is set, it returns a default value
>>>>>>> of 20480.
>>>>>>> *
>>>>>>> * @return size of the session cache; zero means there is
>>>>>>> no size limit.
>>>>>>> * @see #setSessionCacheSize
>>>>>>> */
>>>>>>> public int getSessionCacheSize();
>>>>>>>
>>>>>>> On 11/14/18 11:59 AM, Xuelei Fan wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Please review this simple update:
>>>>>>>> http://cr.openjdk.java.net/~xuelei/8210985/webrev.00/
>>>>>>>>
>>>>>>>> The default value for the maximum number of entries in the SSL
>>>>>>>> session cache (SSLSessionContext.getSessionCacheSize()) is
>>>>>>>> infinite now. In the request, the default value is updated to
>>>>>>>> 20480 for performance consideration.
>>>>>>>>
>>>>>>>> For the detailed behavior update, please refer to CSR:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8213577
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Xuelei
More information about the security-dev
mailing list