On Sat, 12 Mar 2022 00:55:07 GMT, Bradford Wetmore <wetm...@openjdk.org> wrote:

> JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal 
> internal_error (80) and invalidate existing sessions (either completed or 
> under construction) as described in (RFC 4346/TLSv1.1+) if a connection was 
> closed without receiving a close_notify alert from the peer.  
> 
> This change introduces similar behavior to SSLEngine.
> 
> The unit test checks that closing the read(input) sides of the 
> SSLSocket/SSLEngine throws an SSLException, but doesn't invalidate their 
> respective sessions.
> 
> Tier1/2 mach5 tests have been successfully run.

src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java line 799:

> 797:         } finally {
> 798:                 conContext.closeInbound();
> 799:                 engineLock.unlock();

I see that `onContext.closeInbound()` might throw, which would leave the 
`engineLock` locked and could cause deadlocks down the road. So maybe you 
should have a nested `try { } finally { }` here to make sure the lock is 
properly unlocked.

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

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

Reply via email to