[jax-rs-spec users] [jsr339-experts] Re: Filters: comparison of proposed options

From: Bill Burke <>
Date: Wed, 07 Dec 2011 16:29:05 -0500

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