Asynchronous Controller Is Blocking Requests in ASP.NET MVC Through Jquery

Asynchronous Controller is blocking requests in ASP.NET MVC through jQuery

There are two issues in play here. The first is that your controller is not truly asynchronous. Spinning up a ThreadPool thread to perform work generally has worse performance characteristics than just doing everything from within the action method itself, as you're still taking ThreadPool resources from ASP.NET (which just shares the CLR ThreadPool), and you're now forcing the CLR and the OS to juggle threads. See http://msdn.microsoft.com/en-us/library/ee728598.aspx#choosing_synchronous_or_asynchronous_action_methods for more information. Basically, what that link boils down to is that if you can't use I/O completion ports for your asynchronous operations, you're very unlikely to see improved performance.

The second issue is that ASP.NET MVC takes a Session lock on all requests. Multiple requests within a single Session will always be serialized, as otherwise the user's Session could become corrupted if one controller writes to Session as another controller is trying to read it. See http://forums.asp.net/t/1501623.aspx for context and a workaround. MVC 2 Futures has a way of disabling this lock; it may also be included in MVC 3 proper. See Link for more information on this.

AsyncController's async action blocks requests instead of returning immediately

As I describe on my blog, async does not change the HTTP protocol. With HTTP, you get one response per request, and that's it.

A reliable solution is somewhat more complex than what you're thinking. You need a reliable queue (e.g., Azure queue) and an independent backend (e.g., Azure worker role) that processes requests from that queue. Then, your MVC controller can just add a request to the queue and return. Your frontend can then poll for completion or be notified via something like SignalR.

MVC Ajax request without blocking main thread

MVC by default blocks parallel sessions, and there is only one way to avoid it:

[SessionState(SessionStateBehavior.ReadOnly)]

Attribute on Controller and clearly separating logics with using writing and reading sessions.

Asynchronous Asp.Net MVC controller methods?

Will the long run controller method calls block others if they are not asynchronous?

The first important thing to note is that all those controller actions should not have write access to the Session. If they write to the session whether they are sync or async they will always execute sequentially and never in parallel. That's due to the fact that ASP.NET Session is not thread safe and if multiple requests from the same session arrive they will be queued. If you are only reading from the Session it is OK.

Now, the slow controller actions will not block the fast controller actions. No matter whether they are synchronous or not. For long controller actions it could make sense to make them asynchronous only if you are using the asynchronous ADO.NET methods to access the database and thus benefit from the I/O Completion Ports. They allow you to not consume any threads during I/O operations such as database access. If you use standard blocking calls to the database you get no benefit from async actions.

I would recommend you the following article for getting deeper understanding of when asynchronous actions could be beneficial.

Why would multiple simultaneous AJAX calls to the same ASP.NET MVC action cause the browser to block?

The answer was staring me in the face.

ASP.NET Session State Overview:

Access to ASP.NET session state is exclusive per session, which means that if two different users make concurrent requests, access to each separate session is granted concurrently. However, if two concurrent requests are made for the same session (by using the same SessionID value), the first request gets exclusive access to the session information. The second request executes only after the first request is finished.

Annoyingly I'd skimmed paragraph this a couple of weeks ago not really taking in the full impact of the bold sentences. I had read that simply as "access to session state is serialised" and not "all requests, no matter whether you touch session state or not, are serialised" if the requests came from the same session.

Fortunately there is a work around in ASP.NET MVC3 and its possible to create session-less controllers. Scott Guthrie talks about these here:

Announcing ASP.NET MVC 3 (Release Candidate 2)

I installed MVC3 RC2 and upgraded the project. Decorating the controller in question with [SessionState(SessionStateBehavior.Disabled)] solves the problem.

And of course typically I just found this in Stack Overflow a few minutes ago:

Asynchronous Controller is blocking requests in ASP.NET MVC through jQuery

MVC 4.5 Async Ajax call not working

The problem is that your server side action uses ASP.NET Session which is characterized by not being thread-safe. As a consequence, ASP.NET queues parallel requests from the same session and executes them sequentially. Having a RESTful API relying on session is a very bad design and IMHO should be rearchitectured so that it doesn't rely on state.

async jquery call to async mvc controller

Based on image of Chrome console, problem is in SessionState. By default, when application uses SessionState, ASP framework processes requests from single user serially (to prevent session variables from potential corruption).

For cases, when you want to enable parallel processing of requests for single user (and do not need to update session) you can use SessionState attribute on controller.

 [SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly)]

More details can be found for example in here: http://www.stefanprodan.com/2012/02/parallel-processing-of-concurrent-ajax-requests-in-asp-net-mvc/

---

Related Topics