dev@jsr311.java.net

Re: JSR311: Response isn't adequate

From: Bill Burke <bburke_at_redhat.com>
Date: Mon, 10 Mar 2008 13:48:12 -0400

Jerome Louvel wrote:
> Hi Bill,
>
>> Please no. All that silly syntax sugar just to stream?
>
> It's not silly. It might be that you don't understand our arguments yet.
>

I do understand the arguments. But the performance benefit will not be
realized for 95% of applications. Features like Comet and Jetty
continuations are new. People are just starting to use them. There's
already thousands upon thousands of apps that work just fine with
thread-per-request.

> In your proposal, the outputstream would be written by the request thread
> that reaches your resource. Therefore you are stuck with the one thread per
> request model *and* you impose this design to all JAX-RS implementations.
>

Nobody is stuck with anything. If you use a simple model, you get
simple I/O. If you don't, more funky I/O can be done.

> Stephan's proposition is different because you don't expose the outputstream
> to the request/resource thread. The print(OutputStream) method will instead
> be called back by a container's IO/writer thread.
>
>> We're supposed
>> to be making it easier for people to develop. The container can
>> *easily* proxy OutputStream to bridge any funky internal I/O that is
>> going on.
>
> I wish it was that simple. We know how to write proxies, it's easy enough.
> Here it is an important design issue.
>
> How would design your HTTP/IO layer to not have one thread per request,
> while doing streaming the way you propose? You just *can't*.
>

I never said you could. I'm just saying, I don't care if a container's
implementation becomes more difficult or thread-per-request in this
scenario. 95% of applications don't need this asynch I/O. let's make it
easy for 95% of applications that just want to stream output.

If OutputStream is not injected, then there is no issue with container
design, it can perform how you want. This will be the case with a large
number of use cases.

>> I really don't care if vendor implementations are more
>> difficult to write because we want to expose an OutputStream for easy
>> streaming.
>
> You missed the point we are trying to make. Just because we gave bad habits
> to Servlet developers, letting them directly write to the output stream,
> shouldn't force us to carry over this problematic design forever.
>

These arent' bad habits! As I said before, this use case *ONLY* shows
up with the AJAX polling example. Otherwise, NIO buys you nothing but
the overhead of context switching and you are saving *nothing* unless
you are chunking data. I'm not interested in a more complicated
programming model that won't buy me any performance benefit for the
majority of apps.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com