Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Won't Fix
-
2.4.4
-
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
Activity
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.
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.
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