I'm building an ASP.NET MVC site in which the clients(browser) can make API calls that take upto 30 minutes(or more..) to process. Obviously I couldn't use normal MVC Controllers to do this as a few such requests would block all my IIS worker threads leaving other faster calls blocked.
I've looked at the following two options :
- ASP.NET MVC's Asynchronous controllers
- PokeIn Library which allows server push via Reverse AJAX(long holding HTTP requests for older browsers) or WebSockets(from HTML5 specification for newer browsers)
Now both of it seems like a good feasible option.
Option 1 seems easiest for me to implement. With Asynchronous Controllers, my IIS worker threads wouldn't be blocked hence allowing my other faster API calls to go through seamlessly. However from the Async Controller documentation, I perceive that, it spawns of another non IIS thread which would be blocked/waiting for my long running(30~ mins) process to complete. I've read that, "If you block or sleep in a controller no matter whether it is async or not async it is very bad."
In Option 2, if my clients are using newer browsers, which supports WebSockets, this would perhaps be most performant as I do not need to have any blocking thread on the server side. When the client triggers a slow API call I'd raise an event, on the completion of which(say 30~ mins later) I'd raise another event to update all my client's browsers with the updated content. However with PokeIn library, if part of my clients do not have WebSocket supporting browsers(older ones..), I'm not sure If they'd be hogging one of my IIS worker threads.
Is Option 2 an overkill for my requirement ? In Option 1 is it bad to have my Async Controller wait on the slow process ? One other disadvantage with Option 1 is that if the user Refreshes the page before the request completes, He'd no longer get the update of the job, once it completes !
Any ideas, suggestions are welcome.
Thanks