Uploaded image for project: 'Java Driver'
  1. Java Driver
  2. JAVA-4316

The background thread should be able to hand over a new connection to a thread that is blocked by the max connecting limit

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 4.3.0
    • Fix Version/s: 4.3.4
    • Component/s: Connection Management
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Documentation Changes:
      Not Needed

      Description

      Section "Checking Out a Connection" in the CMAP specification says:

      the pool MUST wait to service the request until ... or until a Connection becomes available

      the Pool MUST NOT service any newer checkOut requests before fulfilling the original one which could not be fulfilled

      Currently, DefaultConnectionPool.OpenConcurrencyLimiter.acquirePermitOrGetAvailableOpenedConnection uses a hand over mechanism to implement the above requirements: when a connection is checked in, threads waiting inside acquirePermitOrGetAvailableOpenedConnection are signalled, and are allowed to grab checked in connections before any other thread has a chance to check them out. However, there is another mechanism that may result in available connections appearing in a pool: the background thread populating the pool based on the minSize. Consider the following execution:

      1. tB is the background thread that is establishing a connection to satisfy minSize.
      2. t1 is a thread that is establishing a connection to satisfy a checkout operation.
      3. t2 is a thread that is waiting for a permit to establish a connection to satisfy a checkout, because both permits are taken by tB and t1.
      4. tB completes establishing a connection, t1 continues establishing.
      5. t2 can now either notice that there is a new connection available in the pool and check it out, or take the available permit and start establishing a new connection.

      According to the specification, t2 MUST be the one who gets the connection created by tB, but currently it ignores that connection completely, because the background thread populating the pool does not check new connections in. Instead, populating uses the ConcurrentPool.ensureMinSize method.

      I believe, the background thread (see DefaultConnectionPool.doMaintenance) should be able to use DefaultConnectionPool.OpenConcurrencyLimiter.tryHandOverOrRelease (with some modifications) in order to hand over new connections similarly to how this happens in DefaultConnectionPool.PooledConnection.close. If the background thread successfully hands over a connection, then ConcurrentPool.ensureMinSize must not call ConcurrentPool.release for such a connection.

      This scenario and the way to fix it came to me while I was thinking about JAVA-4288. Fixing this bug will not only make the driver more compliant with the specification, but also will help reducing checkout latencies in situations like that in JAVA-4288. However, on its own, it is unlikely to resolve JAVA-4288.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              valentin.kovalenko Valentin Kavalenka
              Reporter:
              valentin.kovalenko Valentin Kavalenka
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: