MVC Turbine and Async Controllers

[tomas]

Hi, I'm considering using MVC Turbine on a project where we are going
to have high traffic loads, many external webservice calls and a need
to keep the response time to a minimum.
For that I'm considering using async controllers, but I cannot see
that the action is being recognized. Is it easy to extend MVC Turbine
to support async controllers? Or would it rather make more sense to
have normal synchronous controllers, and handle the parallel requests
using Task Paralell Libray or similar.
Thanks!

-Tomas

[Darren Cauthon]

I don't think Turbine changes anything in the MVC framework with
regards to async controllers. What it should be doing is just using
IoC to instantiate the controller. I haven't had to use asynchronous
controllers in a while, so I'll take a look today after work and check
it out.

If using the async controller will do what you need, I'd stick with
that. Don't change just to get around Turbine -- especially because
Turbine should support this already. :)

I'll let you know what I find, unless somebody gets to it first. :)


Darren

[Javier Lozano]

So you're both correct :)

Turbine out of the box registers all IController instances with the
container. The problem here is that an AsyncController is a Controller
and that when the original bits for Turbine were written (and ported
to MVC2) they didn't change or made that distinction :)

The logic within the (default) TurbineControllerFactory is check
whether the newly created controller instance is of type Controller.
If it is, then we ping the container for an IActionInvoker if one is
registered, we use it. Otherwise we use our default one (that provides
inferred actions, filter injection, etc.). As I mentioned earlier, an
AsyncController is a Controller so it passes the "are you of type
Controller?" check and gets an IActionInvoker assigned to it. However,
in order to make the "asynchronous" piece possible, the controller
needs an IAsyncActionInvoker (which it supplies to itself via the
CreateActionInvoker method).

So although Turbine is creating your controllers correctly, it is
assigning the wrong IActionInvoker to them and thus making them not
asynchronous. :( Again, all this code was there in MVC1 when
AsynControllers were not even around; so we'll change the code to
handle them in v2.2! :)

For now you can use this work-around for your controller/
asynccontroller co-habitation; it's a custom controller factory that
inherits from TurbineControllerFactory and performs the "if you're not
of type IAsyncController" logic - http://gist.github.com/534787

The final solution will be slightly different than the one presented
but it will perform the same work. Sorry for this inconvenience and
thank you for bringing up this defect on the code and for checking out
MVC Turbine!

Also, if you do decide to try the code sample and run into any issues
please let me know!

[Javier Lozano]

Also, here's a really awesome read on AsyncControllers by Steve
Sanderson - http://blog.stevensanderson.com/2010/01/25/measuring-the-performance-of-asynchronous-controllers/

He goes into a lot of details on measuring the perf gains from them
and the "gotchas" if you decide to go with them - all the extra work
compared to added perf boost.

On Aug 18, 8:53 am, Javier Lozano <jgloz...@gmail.com> wrote:
> So you're both correct :)
>
> Turbine out of the box registers all IController instances with the
> container. The problem here is that an AsyncController is a Controller
> and that when the original bits for Turbine were written (and ported
> to MVC2) they didn't change or made that distinction :)
>
> The logic within the (default) TurbineControllerFactory is check
> whether the newly created controller instance is of type Controller.
> If it is, then we ping the container for an IActionInvoker if one is
> registered, we use it. Otherwise we use our default one (that provides
> inferred actions, filter injection, etc.). As I mentioned earlier, an
> AsyncController is a Controller so it passes the "are you of type
> Controller?" check and gets an IActionInvoker assigned to it. However,
> in order to make the "asynchronous" piece possible, the controller
> needs an IAsyncActionInvoker (which it supplies to itself via the
> CreateActionInvoker method).
>
> So although Turbine is creating your controllers correctly, it is
> assigning the wrong IActionInvoker to them and thus making them not
> asynchronous. :( Again, all this code was there in MVC1 when
> AsynControllers were not even around; so we'll change the code to
> handle them in v2.2! :)
>
> For now you can use this work-around for your controller/
> asynccontroller co-habitation; it's a custom controller factory that
> inherits from TurbineControllerFactory and performs the "if you're not

> of type IAsyncController" logic -http://gist.github.com/534787

[tomas]

Thanks Javier!
That did the trick.
Just as a note I also had to spesify asych=true on the root
Default.aspx to avoid getting the Async oppreation is not allowed.
I read the link you posted about performance profiling, and I'm still
not sure if we'll go for asych controllers, but it's good to have it
ready, because I for sure want to use turbine now!
Thanks again for your swift reply!
-Tomas

On Aug 18, 4:00 pm, Javier Lozano <jgloz...@gmail.com> wrote:
> Also, here's a really awesome read on AsyncControllers by Steve

> Sanderson -http://blog.stevensanderson.com/2010/01/25/measuring-the-performance-...