On Tue, 27 Apr 2021 16:13:31 GMT, Xue-Lei Andrew Fan <xue...@openjdk.org> wrote:

>> Hello All,
>> 
>> Could you please review the fix for the JDK-8241248?
>> The issue happens during the TLSv1.3 handshake without server stateless 
>> session resumption in case of server receives several parallel requests with 
>> the same pre_shared_key.
>> The main idea of the fix is to remove resuming session from the session 
>> cache in the early stage.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8241248
>> Webrev: http://cr.openjdk.java.net/~abakhtin/8241248/webrev.v0/
>> 
>> The test from the bug report using OpenSSL is passed ( 
>> -Djdk.tls.server.enableSessionTicketExtension=false )
>> javax/net/ssl and sun/security/ssl jtreg tests passed
>> 
>> Regards
>> Alexey
>
> src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java line 
> 377:
> 
>> 375:                     // If we are keeping state, see if the identity is 
>> in the cache
>> 376:                     if (requestedId.identity.length == 
>> SessionId.MAX_LENGTH) {
>> 377:                         synchronized (sessionCache) {
> 
> Did you have a test if there is a performance regression by introducing the 
> synchronization here?
> 
> I have to check the engineGetServerSessionContext() specification and 
> implementation (if the sessionCache is a reference?), and the session cache 
> implementation to make sure the synchronization works (if the synchronization 
> on sessionCache is the same as the synchronization on the cache internal 
> implementation) .  Maybe, the improvement could in the cache implementation 
> for readability?

Yes, I’ve made a test that calculates total time spent by server to receive <N> 
connections. Every server handshake is performed in a separate thread
The client starts <T> threads. Every thread sends one initial connection and 
<R-1> renegotiated connections. So, the total number of connections is  
<N>=<T>*<R>

Results for the original and JDK-8241248 code are almost identical:
<T>=10 <R>=100
Original OpenJDK: 1140 ms
JDK-8241248 code: 1090 ms

<T>=50 <R>=100
Original OpenJDK: 1164 ms
JDK-8241248 code: 1108 ms

<T>=60 <R>=100
Original OpenJDK: 1461 ms
JDK-8241248 code: 1579 ms

<T>=70 <R>=100
Original OpenJDK: 2058 ms
JDK-8241248 code: 1999 ms

<T>=80 <R>=100
Original OpenJDK: 2148 ms
JDK-8241248 code: 2125 ms

<T>=90 <R>=100
Original OpenJDK: 2540 ms
JDK-8241248 code: 2514 ms

<T>=90 <R>=100
Original OpenJDK: 3011 ms
JDK-8241248 code: 3010 ms

I can confirm that the synchronization code works. Without it I still catches 
exception from different threads trying to resume the same session from the 
cache

-------------

PR: https://git.openjdk.java.net/jdk/pull/3664

Reply via email to