Async methods with Memcached buckets


#1

Hi,
I’m trying to switch to the new async methods in my Asp.Net MVC application but I saw that the OpenBucket call never ending with a Memcached bucket but it works with a Couchbase one.
Is this a Memcached bucket’s limitation?
Thanks :wink:


#2

Hi @kf-marco.v

The cluster.OpenBucket method should return in the same way and I don’t have a problem opening buckets or executing async calls to a memcached bucket.

Can you share a code sample with that you’re trying to do?

Thanks


#3

Hi Mike,
this is my Console Application’s Program class:

    private static void Main(string[] args)
        {
            AsyncContext.Run(() => MainAsync(args));
        }
        private static async Task MainAsync(string[] args)
        {
            using (var cluster = new Cluster("couchbaseClients/couchbase"))
            {
                using (var bucket = cluster.OpenBucket("test"))
                {
                    var document = new Document<dynamic>
                    {
                        Id = "Hello",
                        Content = new
                        {
                            name = "Couchbase"
                        }
                    };

                    var upsert = await bucket.UpsertAsync(document);
                    if (upsert.Success)
                    {
                        var get = await bucket.GetDocumentAsync<dynamic>(document.Id);
                        document = get.Document;
                        var msg = string.Format("{0} {1}!", document.Id, document.Content.name);
                        Console.WriteLine(msg);
                    }
                    Console.Read();
                }
            }
        }

I’m using Nito.AsyncEx for the async context.

With e memcached bucket the Console output can’t go further the bucket using line without errors.
The Couchbase server is the 4.5.1 version.

Thanks
Marco


#4

@kf-marco.v

It might be an issue with a SynchronizationContext being added. Can you try it with Task.Run instead of AsyncContext.Run and see if it behaves differently? Also, I’d be curious if it behaves differently if you open the bucket from within Main and just try to use it within the async method.

Brant


#5

Hi Brant,
I tried to execute all the program in the Main method using the Result property of the Async methods :poop: and the UpsertAsync fails with an Timeout Operation Exception:

private static void Main(string[] args)
        {
            using (var cluster = new Cluster("couchbaseClients/couchbase"))
            {
                using (var bucket = cluster.OpenBucket("test"))
                {
                    var document = new Document<dynamic>
                    {
                        Id = "Hello",
                        Content = new
                        {
                            name = "Couchbase"
                        }
                    };

                    var upsert = bucket.UpsertAsync(document).Result;
                    if (upsert.Success)
                    {
                        var get = bucket.GetDocumentAsync<dynamic>(document.Id).Result;
                        document = get.Document;
                        var msg = string.Format("{0} {1}!", document.Id, document.Content.name);
                        Console.WriteLine(msg);
                    }
                    Console.Read();
                }
            }
        }

With a Couchbase bucket it works like expected :+1:


#6

Hi @kf-marco.v

I’ve been able to reproduce the non-returning OpenBucket for Memcached buckets when using Nito.AsyncEx and agree with @btburnett3 that it is likely due to the synchronisation context being used and causing something to block within the library.

When not using the Nito.Async library, I can open both Couchbase and Memcached buckets but do see a significant delay (10 seconds) when opening Memcached buckets. The bucket does seemed to perform as expected once it was open.

I’ve created the following tickets to investigate the two problems you have reported. If you would like to help find / fix the bugs I would be happy to help. If not, I’ll add these to our backlog for future prioritisation.

https://issues.couchbase.com/browse/NCBC-1395
https://issues.couchbase.com/browse/NCBC-1396

Please can you confirm your CouchbaseNetClient version, cluster version and the Couchbase web.config section?

Thanks


#7

Hi

Yes correct

In this case I can open both the buckets too but the UpsertAsync for the Memcached version fails.

The CouchbaseNetClient is the 2.4.4 version, the cluster is the 4.5.1-2845 version and this is my web.config section:

<couchbase useSsl="false">
      <servers>
        <add uri="http://localhost:8091/pools"></add>
      </servers>
      <buckets>
        <add name="test" useSsl="false" password="test" operationLifespan="2000">
          <connectionPool name="custom" maxSize="10" minSize="5" sendTimeout="12000"></connectionPool>
        </add>
        <add name="testm" useSsl="false" password="testm" operationLifespan="2000">
          <connectionPool name="custom" maxSize="10" minSize="5" sendTimeout="12000"></connectionPool>
        </add>
      </buckets>
    </couchbase>

Thanks


#8

Thank you, @kf-marco.v


#9

What errors are you getting? Can you post them?


#10

Hi,
I tried the version without the Nito Async context with the latest Couchbase library on GitHub (not that on NuGet) and it works!

With the Nito.Async library I have no errors: the console app waiting forever…


#11

@kf-marco.v -

Yeah, I don’t think its related to Nito, instead its this issue: NCBC-1383

-Jeff


#12

Hi,
I tried to update to the latest 2.4.6 version but now every Upsert fails :astonished:

I’ve only updated the client version… and with the branched version is the same: with the 2.4.5 it works.

Marco


#13

@kf-marco.v -

Can you provide the response status and stacktrace if available?

-Jeff


#14

Hi,
the Exception is : “The operation has timed out.” and Status “TransportFailure”.

My local server is the 4.6.2-3905 version.

Thanks
Marco


#15

@kf-marco.v -

This was a bug and is fixed in 2.4.7 as part of this ticket.

-Jeff