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

Connection terminated when packet exceeds NetworkStream buffer size

    XMLWordPrintable

Details

    • Task
    • Resolution: Fixed
    • Major
    • 3.0.0
    • 3.0.0-beta.4
    • library
    • None
    • 1

    Description

      Possible bug when running multiple (hundreds) of GetAsync requests in parallel...(we have a workaround so not urgent, but would be interested in feedback on the following):

      We have a wrapper for GetAsync that looks like this:

      public async Task<T> GetAsync(string key)
      {
         try {
            var result = await ICouchbaseCollectionObj.GetAsync(key);
            return result != null ? result.ContentAs<T>() : default(T);
         } catch () { ... }
      }
      

      I am seeing exceptions in the logs as follows...
      System.NullReferenceException: Object reference not set to an instance of an object.
      at Couchbase.KeyValue.GetResult.ParseSpecs()
      at Couchbase.KeyValue.GetResult.ContentAs[T]()

      Is there a way to check if the _contents of the result are null? Is this a bug? How is that we can we get a valid result back from GetAsync, but trying to then access the _contents of the result fails?

      Note that we only typically see this when we are calling GetAsync(key) in parallel for hundreds of keys by using a "GetMultiAsync" wrapper to our "GetAsync" wrapper as follows:

      public async Task<Dictionary<string,T>> GetMultiAsync<T>(string[] keys)
      {
         var result = new ConcurrentDictionary<string, T>();
         try
         {
            var GetAsyncTasks = keys.Select(async key =>
               { 
                  var document = await GetAsync<T>(key);
                  if (document != null) {
                     result.TryAdd(key, document);
                  }
               });
            await Task.WhenAll(GetAsyncTasks);
         } catch () { ... }
         return new Dictionary<string, T>(result);
      }
      

      When this occurs, the document for the key is not retrieved even though we can see from the CB UI that the document is there and is what we expect it to be.

      Attachments

        For Gerrit Dashboard: NCBC-2414
        # Subject Branch Project Status CR V

        Activity

          People

            jmorris Jeff Morris
            jmorris Jeff Morris
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes

                PagerDuty