Qpid
  1. Qpid
  2. QPID-4257

Windows+SSL: Client hang on broker close, broker memory leak

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18, 0.19
    • Fix Version/s: 0.19
    • Component/s: C++ Broker, C++ Client
    • Labels:
    • Environment:

      Windows client on Windows 7, Windows broker on Server 2K8, using SSL.

      Description

      Windows clients hang when broker dies via SSL connection - fetch never returns even w/ IMMEDIATE timeout.
      Windows broker memory grows linearly with SSL connection count, leak per connection, until broker exhausts memory and crashes.

        Activity

        Hide
        Chuck Rolke added a comment -

        Fixed with r1382026

        Show
        Chuck Rolke added a comment - Fixed with r1382026
        Hide
        Chuck Rolke added a comment -

        I've posted an improved patch for review. With this patch the connection closure is signalled through to clients and the clients wake up. The one-second timeout clamp is not necessary any more.

        https://reviews.apache.org/r/6948/

        Description
        -------

        Based on original work by Kerry Bonin in QPID-4257. The Windows SslConnector fails to properly relay connection events causing memory leaks and client hangs.
        With this patch the memory leaks are improved[1] and clients doing fetch(FOREVER) are woken properly.

        Diff: https://reviews.apache.org/r/6948/diff/

        [1] Windows clients using SSL or not still seem to leak about 1Kb per connection even with this patch. That may be treated as a separate issue.

        Show
        Chuck Rolke added a comment - I've posted an improved patch for review. With this patch the connection closure is signalled through to clients and the clients wake up. The one-second timeout clamp is not necessary any more. https://reviews.apache.org/r/6948/ Description ------- Based on original work by Kerry Bonin in QPID-4257 . The Windows SslConnector fails to properly relay connection events causing memory leaks and client hangs. With this patch the memory leaks are improved [1] and clients doing fetch(FOREVER) are woken properly. Diff: https://reviews.apache.org/r/6948/diff/ [1] Windows clients using SSL or not still seem to leak about 1Kb per connection even with this patch. That may be treated as a separate issue.
        Hide
        Chuck Rolke added a comment -

        Kerry,

        Thanks for posting the patch. I will give it some attention.

        Chuck

        Show
        Chuck Rolke added a comment - Kerry, Thanks for posting the patch. I will give it some attention. Chuck
        Hide
        Kerry Bonin added a comment -

        Patch to correct.

        GetQueuedCompletionStatus was not being signaled properly when an SSL connection was closed remotely, so it never returned from a INFINITE timeout. Patched to clamp timeout to 1 second, existing logic handled return w/ numTransferred=0 case, and GetQueuedCompletionStatus did return false without signaled exit when SSL had been remotely closed. This corrected the hang.

        Added SslConnector::redirectDisconnect, as the eof() logic in qpid::client::TCPConnector wasn't properly signalling closure and releasing resources.

        Show
        Kerry Bonin added a comment - Patch to correct. GetQueuedCompletionStatus was not being signaled properly when an SSL connection was closed remotely, so it never returned from a INFINITE timeout. Patched to clamp timeout to 1 second, existing logic handled return w/ numTransferred=0 case, and GetQueuedCompletionStatus did return false without signaled exit when SSL had been remotely closed. This corrected the hang. Added SslConnector::redirectDisconnect, as the eof() logic in qpid::client::TCPConnector wasn't properly signalling closure and releasing resources.

          People

          • Assignee:
            Unassigned
            Reporter:
            Kerry Bonin
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 168h
              168h
              Remaining:
              Remaining Estimate - 168h
              168h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development