Uploaded image for project: 'Couchbase .NET client library'
  1. Couchbase .NET client library
  2. NCBC-2643

DataFlowConnectionPool creates connections unbounded in certain situations

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 3.0.5
    • 3.1.0
    • library
    • None
    • 1

    Attachments

      No reviews matched the request. Check your Options in the drop-down menu of this sections header.

      Activity

        jmorris Jeff Morris added a comment -

        May move to 3.0.7

        jmorris Jeff Morris added a comment - May move to 3.0.7
        jmorris Jeff Morris added a comment - - edited

        If you check the exception type for AuthenticateException and do not throw it but just log it then it works. https://github.com/couchbase/couchbase-net-client/blob/master/src/Couchbase/Core/ClusterNode.cs#L557-L580

        If you catch it and then just do a connection.CloseAsync in the catch, then the connections still keep increasing just at a much lower rate as they eventually get reclaimed, but not fast enough to keep the slope flat.

        Note that in my fix, if you add the bucket and the indexes, the connection count stays the same and then the logged failures become successes as expected. Which is perfect; my fear here is that were hiding errors instead of percolating them up.

        There is still a bug in that if any other exception is thrown, the sdk will leak the connection, which will need to be fixed. For this case I feel like we need a flag to enable the behavior if required, but default to closing the connection and letting the exception bubble up.

        jmorris Jeff Morris added a comment - - edited If you check the exception type for AuthenticateException and do not throw it but just log it then it works. https://github.com/couchbase/couchbase-net-client/blob/master/src/Couchbase/Core/ClusterNode.cs#L557-L580 If you catch it and then just do a connection.CloseAsync in the catch, then the connections still keep increasing just at a much lower rate as they eventually get reclaimed, but not fast enough to keep the slope flat. Note that in my fix, if you add the bucket and the indexes, the connection count stays the same and then the logged failures become successes as expected. Which is perfect; my fear here is that were hiding errors instead of percolating them up. There is still a bug in that if any other exception is thrown, the sdk will leak the connection, which will need to be fixed. For this case I feel like we need a flag to enable the behavior if required, but default to closing the connection and letting the exception bubble up.

        People

          btburnett3 Brant Burnett
          jmorris Jeff Morris
          Votes:
          1 Vote for this issue
          Watchers:
          4 Start watching this issue

          Dates

            Created:
            Updated:
            Resolved:

            Gerrit Reviews

              There are no open Gerrit changes

              PagerDuty