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

Opening Memcached buckets when using Nito.Async library never returns

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Minor
    • Resolution: Won't Fix
    • 2.4.4
    • backlog-2.0, .backlog
    • None
    • None

    Description

      When trying to open a memcached bucket when using the Nito.Async library the OpenBucket method never returns, this is likely due to some context synchronisation issue. Opening Couchbase buckets does not see the same blocking behaviour.

      The issue was reported in this forum post

      Attachments

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

        Activity

          Mike Goldsmith

          I've been trying to reproduce this on my machine with no luck.  I've tried just about every combination of things I can think of.  But, with threading problems, it can be pretty difficult.  My best guess is that it's catching on some machines here: https://github.com/brantburnett/couchbase-net-client/blob/a8e53500f29d3e4fc627da0e407e52a2c5adc482/Src/Couchbase/Configuration/Server/Providers/Streaming/HttpStreamingProvider.cs#L76

          Looking at the source for Nito.AsyncEx.Context, running within AsyncContext.Run is basically forcing the entire async execution onto a single thread.  So if the .Result call kicks off before the HTTP request starts, the only available thread is now blocked. It comes down to if the task scheduler decides to try to run synchronously or not.  It's probably causing similar issues in other places as well where we're using SynchronizationContextExclusion and .Result.  That's my best guess, anyway.

          The thing is, I'm not really sure that this is a use case we should bother supporting.  If there's a reason forcing the entire async process into a single thread makes sense in an environment using Couchbase, I'm missing it.

          Brant

          btburnett3 Brant Burnett added a comment - Mike Goldsmith I've been trying to reproduce this on my machine with no luck.  I've tried just about every combination of things I can think of.  But, with threading problems, it can be pretty difficult.  My best guess is that it's catching on some machines here: https://github.com/brantburnett/couchbase-net-client/blob/a8e53500f29d3e4fc627da0e407e52a2c5adc482/Src/Couchbase/Configuration/Server/Providers/Streaming/HttpStreamingProvider.cs#L76 Looking at the source for Nito.AsyncEx.Context, running within AsyncContext.Run is basically forcing the entire async execution onto a single thread.  So if the .Result call kicks off before the HTTP request starts, the only available thread is now blocked. It comes down to if the task scheduler decides to try to run synchronously or not.  It's probably causing similar issues in other places as well where we're using SynchronizationContextExclusion and .Result.  That's my best guess, anyway. The thing is, I'm not really sure that this is a use case we should bother supporting.  If there's a reason forcing the entire async process into a single thread makes sense in an environment using Couchbase, I'm missing it. Brant

          Hey Brant Burnett

          With the code you highlighted, I wasn't sure it was possible to schedule the Result of a task before the task has begun but as I type it out, I guess it would be because it has no way of knowing even though it's chaining them together. However, I would have expected intermittent behaviour as the Task scheduler would sometimes select the HTTP request to execute first, where I think the OP suggests it was consistent.

          Also agree this is probably a low priority for us to address as the majority of developers would not be using Nito, or something else, to limit the web server to one thread.

          mike.goldsmith Michael Goldsmith added a comment - Hey Brant Burnett With the code you highlighted, I wasn't sure it was possible to schedule the Result of a task before the task has begun but as I type it out, I guess it would be because it has no way of knowing even though it's chaining them together. However, I would have expected intermittent behaviour as the Task scheduler would sometimes select the HTTP request to execute first, where I think the OP suggests it was consistent. Also agree this is probably a low priority for us to address as the majority of developers would not be using Nito, or something else, to limit the web server to one thread.
          jmorris Jeff Morris added a comment -

          Marking these as closed and "Wont fix" as they are old and align with sdk2 which is now EOL. If you disagree (customer escalation for example), please reopen and assign to me with the reason for reopening.

          jmorris Jeff Morris added a comment - Marking these as closed and "Wont fix" as they are old and align with sdk2 which is now EOL. If you disagree (customer escalation for example), please reopen and assign to me with the reason for reopening.

          People

            Unassigned Unassigned
            mike.goldsmith Michael Goldsmith
            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