JDK-8258753 : StartTlsResponse.close() hangs due to synchronization issues
  • Type: Bug
  • Component: core-libs
  • Sub-Component: javax.naming
  • Affected Version: 8u261,11,17
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-12-21
  • Updated: 2021-07-30
  • Resolved: 2021-03-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 8 Other
11.0.12Fixed 8u291Fixed openjdk8u302Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Fix request (15u) I'd like to backport it here, too. The patch applies cleanly, tier tests run OK.

Fix request (8u) I'd like to have this bug fix backported to 8u. The 11u patch applies cleanly once the file paths are converted to the previous scheme. No regressions found in jdk/sun/security/ssl tests category.

Fix Request (11u) This fixes the race condition in SSL code and keeps codebases in sync (I see 11.0.12-oracle). Patch applies cleanly to 11u, passes tier{1,2} and javax/net/ssl tests.

Fix Request [16u] Requesting backport of this change to resolve race condition between SSL close and read operation further causing the application to hang. The patch applied cleanly to JDK-16u (only copyright has been updated) and was tested with Mach5 tiers 1, 2 and 3 on Linux, Mac OS, Solaris and Windows.

Changeset: 41555332 Author: Prajwal Kumaraswamy <pkumaraswamy@openjdk.org> Committer: Xue-Lei Andrew Fan <xuelei@openjdk.org> Date: 2021-03-25 03:35:49 +0000 URL: https://git.openjdk.java.net/jdk/commit/41555332

Going through the 8u251 and 8u261 code, there seems to be a synchronization issue in 8u261. The 8u251 code has synchronized the read operation with a read object lock and either client/main thread can perform read operation at a time. Once client/main thread reads the close_notify acknowledgment from the server, the connection state will be set to closed. Although the main/client thread gets access to read lock (after client/main threads reads close_notify acknowledgment from server), there is a condition before reading from the socket i.e. only if the connection is not closed then fetch the data from the socket. If the connection is closed, then input stream gets closed and exits gracefully without trying to read from socket hence there is no hang or error. In case of 8u261, we do not have a synchronization for read operation and below are the 2 issues observed. 1. Client/Main thread reads the close_notify acknowledgment from server. Further, Main/Client thread (whichever doesn't read ack from server) tries to read from the socket again and waits until SocketTimeOutException, since input buffer is empty. 2. Client/Main thread tries to read from the socket at the same time but gets "Insufficient buffer" error