On 12/7/11 5:26 AM, Marek Potociar wrote:
> Now I am not saying that we should address such scenarios right away or that we should expose our users to any complex
> implementation details around fork-join or any other execution strategy. But this is just to demonstrate what we may
> expect to deal with in the future, esp. if we, as implementors, want to leverage the parallel/async execution to gain
> performance boosts. That should help us to produce design flexible enough to support these types of scenarios. If all
> that we have to do right now is to convert an existing enum into an opaque interface and add bunch of action methods
> into the FilterContext, then I wonder why don't we just do it?
>
Running filters in parallel for the same request seems pretty crazy to
me. In fact, its kinda silly. The context switching/joining alone
would kill any performance gains you made. Plus, any modicum of request
concurrency will already max out the cores of your CPU(s). All this
crazy I/O you're talking about would rarely (if ever) happen in a
filter. It would happen in application code.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com