Bill,
I already said that I wasn't considering AJAX/Comet as a use case we need to
support. So, I'm not going to repeat all the arguments over and over.
There are definitely some scalability issues that you don't want to
consider. Just today, we were discussing in the Restlet list such use case.
http://thread.gmane.org/gmane.comp.java.restlet/4411
It's not AJAX, it's not Comet, it's about dealing with large volumes of data
and large number of concurrent requests. It could also be about dealing with
slow clients/slow networks and with JVM/OS that can afford unlimited number
of threads.
That's your choice to stick with a thread-per-request model, but I don't
think you should impose this on other implementations who want to achieve
better performance and scalability. Marc and Stephan proposed balanced
solutions that seem reasonable to me, even if they add a little more
complexity from your point of view.
Best regards,
Jerome
> -----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
>