Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8263743

redundant lock in SSLSocketImpl

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 17
    • Component/s: security-libs
    • Labels:

      Description

      In the SSLSocketImpl, there is a socket level lock while reading application data (see readApplicationRecord).

                      socketLock.lock();
                      try {
                          plainText = decode(buffer);
                      } finally {
                          socketLock.unlock();
                      }

      If an application data read is in progress, other calling to SSLSocket APIs (for example getUseClientMode()) could be blocked if socket level locks are used.

      This is not an easy to reproduce bug because readApplicationRecord() will try to read the TLS header at first, and then lock the socket. Normally, a TLS record could be delivered in one package, and thus the socket level lock in readApplicationRecord() does not block. But if the TLS record is delivered in multiple packages, the socket level lock may take a while and thus could block other APIs.

      The decode() method is used in two places. One for the initial handshaking, and one for application data reading. The application data reading does not start before the initial handshaking completed. So it is not necessary to have a lock to synchronize the initial handshaking and application data reading.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              xuelei Xue-Lei Fan
              Reporter:
              xuelei Xue-Lei Fan
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: