dev@jsr311.java.net

Re: JSR311: Response isn't adequate

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Mon, 10 Mar 2008 14:46:11 -0400

On Mar 10, 2008, at 2:22 PM, Jerome Louvel wrote:
> Marc and Stephan proposed balanced
> solutions that seem reasonable to me, even if they add a little more
> complexity from your point of view.
>
Bill also suggested:

> @GET
> public Representation get()
> {
>
> Connection conn = ...;
> Blob blob = rs.getBlob(...);
>
> return new Representation() {
> public write(OutputStream stream) {
> // stream the output
> blob.close();
> rs.close();
> conn.close();
> }
> };
>
> }

Which is actually pretty similar to Stephan's:

> @GET
> public Object get()
> {
> // ...
> return new javax.ws.rs.StreamingOutput() // interface with one
> method
> {
> public void print(java.io.OutputStream out) // perhaps more
> parameters
> {
> out.write(...)
> out.write(...)
> out.write(...)
> out.write(...)
> out.write(...)
> }
> }
> }


and not really that different from my:

> @GET
> public InputStream get() {
>
> Connection conn = ...;
> Blob blob = rs.getBlob(...);
>
> return new InputStream() {
> InputStream is = blob.getBinaryStream();
>
> public int read() throws IOException {
> return is.read();
> }
>
> public void close() throws IOException {
> is.close();
> blob.close();
> rs.close();
> }
> };
> }

Marc.



>
>> -----Message d'origine-----
>> De : Bill Burke [mailto:bburke_at_redhat.com]
>> Envoyé : lundi 10 mars 2008 18:48
>> À : dev_at_jsr311.dev.java.net
>> Objet : Re: JSR311: Response isn't adequate
>>
>>
>>
>> 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
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.