async, await, synchronization context : need help and explanation to build a real asynchronous app

[julienGrd]

Hello guys, i work since two years to migrate a silverlight app in blazor. Im now close to put this on production but i still have a big problem before release : it seem when a wcf service is called (we don't migrate the backend for now), the others are in "pending" and wait the first has been completed before execute the call.

I already made some research and found it can be considered as a normal behavior because of the single thread behavior of webassemby
https://docs.microsoft.com/en-us/aspnet/core/blazor/components/?view=aspnetcore-5.0#synchronization-context

https://stackoverflow.com/questions/64714907/unable-to-have-real-asynchronous-service-with-wcf-client-on-net-5-0-one-call/64814305#64814305

At this point i can separate two types of calling and priorize them :

• asynchronous with results : its better but not mandatory. It's a regression from silverlight app but i can deal with that (even if i hope you will make this working soon, like .NET 6.0, because its a really important functionnality of modern app). So if you think its possible now in blazor, please share some tips on how we can implement that.
• asynchronous without results : To be more precise, have the ability to call a one-way service during another one (which this last one waiting for results)
  The reason of this behavior is we have an "ImAlive" service launch by a timer on client side. This OneWay service is here to prevent user be disconnected on the wcf server if he do nothing on the app (for this scenario its ok because i dont wait for another thing), and also being user not disconnected during long treatment (for this one its a no-go).

I already try to put some .ConfigureAwait(false) as i see on different blog/forums everywhere in my chain of async/await but its change nothing (on my LongTreatmentWithResult service and on my ImAlive service).

Because my ImAlive service is OneWay and i don't need to wait for him, i was thinking remove all the await before the calls (chain of calling) of my ImAlive service would made this working (i have warnings on my call with this but if its work...). But even with this its not work, i never reached the wcf server until the LongTreatment have completed.

So guys have you a solution for me ? Thanks for your help

[javiercn]

@julienGrd thanks for contacting us.

This goes a bit beyond of the types of issues/questions we try to answer here, but I'll try to give you some pointers despite that.
It's not clear to me whether this is from a Blazor server application or a Blazor Webassembly app, but I'm going to assume this is server-side Blazor.

For Blazor webasembly there is only one thread, since that's what JavaScript provides today (and the .NET runtime doesn't support multi-threading in wasm).

This is why we always tell people not to call .Result or .Wait(), since those things will block the thread, and when async work continues it will not be able to "resume" as the only available thread is blocked.

There is obviously multi-threading in ASP.NET Core apps, but Blazor Server uses a synchronization context to emulate the single thread behavior in webassembly. Otherwise your component would behave very differently on WebAssembly compared to Server.

The synchronization context in ASP.NET Core only takes care of ensuring that only one thread is running code at a time for a given Blazor server session.

When you do await, what happens is the compiler does some magic and ends up calling Task.ContinueWith that continuation is scheduled to run via the TaskScheduler, which will normally run the code within a thread from the threadpool.

Now is when the synchronization context comes into play, if your framework has one, it will be preserved and restored within the await call, and the continuation that the framework uses will call a method on the synchronization context along with the actual continuation.

Then the responsibility of the synchronization context is to determine where that code needs to run, on Windows forms or WPF it runs on the UI thread, on old ASP.NET it ran on any thread on the thread pool and in Blazor it runs on another thread from the thread pool, but ensures that only one of them runs at a time.

Now, whether you are using SSB or Blazor Wasm, the answer should be the same, you can't call .Wait() or .Result since that will end up blocking the thread and continuations won't be able to resume.

There are several patterns to "workaround" this, but ultimately if your call is blocking there's nothing to do.

Hope this helps.

[julienGrd]

@javiercn thanks for your response

It's not clear to me whether this is from a Blazor server application or a Blazor Webassembly app, but I'm going to assume this is server-side Blazor.

My app can run in both mode. In webassembly mode the wcf call is made by the hosting asp.net core server (because webassembly cant call directly wcf service). So in both mode the wcf services are calling by asp .net core

Now, whether you are using SSB or Blazor Wasm, the answer should be the same, you can't call .Wait() or .Result since that will end up blocking the thread and continuations won't be able to resume.

There is no wait or Result in my app, everything is made with async and await

There are several patterns to "workaround" this, but ultimately if your call is blocking there's nothing to do.

So you confirm its impossible now to make two parralel call to wcf services, even if we don't wait for response ? do you have some tips about these "'workarounds" ?

Sorry for polluted this forum with an "help" question but asynchronism is now a basic pattern and im really surprised something was working perfectly in a ten years old silverlight app can't work in a fresh .NET 5 blazor app.

[mrpmorris]

I'm not sure if I am missing the issue here or not, I've only just woken up :) Have you tried this?

var t1 = FirstCallAsync();
var t2 = SecondCallAsync();
await Task.WhenAll(t1, t2);

Those will run in parallel. Except chrome will run them in sequence of they are too the same url - in which case add a random guid to the query string or set a request header telling Chrome not to use the cache.

[javiercn]

@julienGrd thanks for the additional clarifications.

Let me scope my answer a bit more.

If everything is using tasks and async/await and doing async work (the implementation "yields" when it goes async) it is perfectly possible (modulo browser behaviors like the one described by @mrpmorris) to run multiple things simultaneously.

For example, what @mrpmorris should work just fine.

I'm not sure we'll be able to help you any further without more concrete bits of code, I'm going to mark this as answered since it's a bit off-topic for this issue tracker.

[julienGrd]

@mrpmorris Thanks for your response. In my case i can't make this because its not my code which decide which services are called by the action of the user, see my scenario at the bottom

@javiercn : let me give you a simpe example.

a page with two button Service1 and Service2, respectively launching Service1 and Service2

The service 1 is a wcf service which take 10 minutes before returning response
The Service 2 is also a wcf service, one way or not, we don't care it will be the same behavior

everything between the click and the button and the call of the wcf service respect async/await

if the user click on Service1, i call the service and expect a response 10 minutes later. I can for example show a message when i write : "Treatment will take 10 minutes, a popin whill show you the result".

During this time, the user can continue using the app without problem, so the async/await pattern works perfectly in this case.

Now let click on the button Service2, What Happen is if i put a breakpoint on the implementation of the wcf service Service2, i never reached them. actually i will reached them when Service1 will be finished. on asp .net core app, you see the call blocking where the wcf called is made (and not before);

So the question now :
do you consider this as a normal behavior ?if no, i can create this kind of small program to demonstrate them, if needed.

thanks again for your time !

[javiercn]

@julienGrd unfortunately I don't think there's enough details for me to give you a better answer.

The scenario is not clear to me, if you can put a code snippet I might be able to clarify things further or give more targeted guidance.

I would suggest (again, without exact understanding on what the scenario is) that you avoid awaiting the first WCF call at the top level of your handler and instead wrap the async call within some exception handling code or store the task in a field if you need to know when the task has finished.

[julienGrd]

@javiercn ok, i will be able tu make a repro project in few days. Can you put this issue in waiting state or somethink like that but please dont close it its really important for our company, it actualy blocking a two years of work project !

thanks !

[julienGrd]

ok guys after some tests is not directly related to aspnet core but its my wcf server which seem blocking the request if the other one with same sessionId (set by cookie in my wcf client) are not finished. If no sessionId by cookie is set then wcf server handle the call asynchronously.

I read lot of stuff of this problem on internet but no one was able to solve our problems, we can't deactivate session on the wcf server because everything is based on it. The more surprising is the silverlight app don't have this problem without specific configuration.

In fiddler i don't see specific difference between the silvelight request and the aspnetcore request,but one is blocked (waiting) and the other not.

We are pretty desesperate, if you have an ultimate advice on this we take it otherwise you can close this issue