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

On OSX default connection pool hangs when doing bulk async/await ops

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 2.4.0-dp2
    • 2.4.0
    • library
    • None

    Description

      Work-around is to use MUX IO:

      //first add the appropriate using statements to the class header:
      using Couchbase.IO;
      using Couchbase.IO.Services;
       
      ....
       
      // later create a client configuration and pass into the ClusterHelper.Initialize or the Cluster ctor:
       var config = new ClientConfiguration
       {
              Servers = new List<Uri> {new Uri("http://localhost:8091/")},
       };
       config.ConnectionPoolCreator = ConnectionPoolFactory.GetFactory<ConnectionPool<MultiplexingConnection>>();
       config.IOServiceCreator = IOServiceFactory.GetFactory<MultiplexingIOService>();
       ClusterHelper.Initialize(config);
      

      Attachments

        Issue Links

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

          Activity

            jmorris Jeff Morris added a comment -

            Michael Goldsmith -

            I believe you'll need logging to work NCBC-933 before you can diagnose what is going on here. The other ticket CBSE-3210 gives the back story.

            -Jeff

            jmorris Jeff Morris added a comment - Michael Goldsmith - I believe you'll need logging to work NCBC-933 before you can diagnose what is going on here. The other ticket CBSE-3210 gives the back story. -Jeff
            jmorris Jeff Morris added a comment -

            I changed this from a blocker to major since there is a work-around: use muxio. The solution may be to default the SDK to muxio for 2.4.0.

            jmorris Jeff Morris added a comment - I changed this from a blocker to major since there is a work-around: use muxio. The solution may be to default the SDK to muxio for 2.4.0.

            The one worry with changing to muxio as default is we'll need to be really clear about all of those other tuneables that no longer do anything.  Maybe this is just a change we need to take on.

            ingenthr Matt Ingenthron added a comment - The one worry with changing to muxio as default is we'll need to be really clear about all of those other tuneables that no longer do anything.  Maybe this is just a change we need to take on.
            jmorris Jeff Morris added a comment -

            Indeed, that is the only compelling reason to not switch to muxio as the default IO strategy; the PoolConfiguration.MaxSize and PoolConfiguration.MinSize properties will become obsolete. One solution that has been discussed is to have a pool of muxio and then assign a connection from the pool to a set of threads or perhaps a hash index (or similar concept) of a key that's already mapped to a node. This hasn't been worked on and wasn't planned for 2.4.0 scope.

            jmorris Jeff Morris added a comment - Indeed, that is the only compelling reason to not switch to muxio as the default IO strategy; the PoolConfiguration.MaxSize and PoolConfiguration.MinSize properties will become obsolete. One solution that has been discussed is to have a pool of muxio and then assign a connection from the pool to a set of threads or perhaps a hash index (or similar concept) of a key that's already mapped to a node. This hasn't been worked on and wasn't planned for 2.4.0 scope.

            I think the 2.4.0 release is a good time to move to MuxIO if we really do think it is a better long-term solution. As Matt Ingenthron suggests, we can be very explicit about the change in our release notes.

            mike.goldsmith Michael Goldsmith added a comment - I think the 2.4.0 release is a good time to move to MuxIO if we really do think it is a better long-term solution. As Matt Ingenthron suggests, we can be very explicit about the change in our release notes.
            jmorris Jeff Morris added a comment -

            Yes, that is the plan - I'll create a ticket shortly. It would be interesting to see if updating the Core dependencies has any effect (NCBC-1238).

            jmorris Jeff Morris added a comment - Yes, that is the plan - I'll create a ticket shortly. It would be interesting to see if updating the Core dependencies has any effect ( NCBC-1238 ).

            Using Todd's sample-code I created a .NET core console app working against a two-node 4.5.1 cluster built using vagrant. With a workload of 50k document upserts, they produced the following timings:

            OSX (Visual Studio for Mac):
            149.5 s
            172.3 s
            179.2 s

            Windows 10 (Visual Studio 2017):
            172.5 s
            145.9 s
            184.4 s

            Todd Greenstein [X] Can you provide any more info on your code setup / cluster setup?

            mike.goldsmith Michael Goldsmith added a comment - Using Todd's sample-code I created a .NET core console app working against a two-node 4.5.1 cluster built using vagrant. With a workload of 50k document upserts, they produced the following timings: OSX (Visual Studio for Mac): 149.5 s 172.3 s 179.2 s Windows 10 (Visual Studio 2017): 172.5 s 145.9 s 184.4 s Todd Greenstein [X] Can you provide any more info on your code setup / cluster setup?

            People

              tgreenstein Todd Greenstein [X] (Inactive)
              jmorris Jeff Morris
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes

                  PagerDuty