Jerome Louvel wrote:
> 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.
>
And I'm saying that your model buys you nothing but the overhead of
context switching.
> 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.
>
The email thread you are referring to above cannot be implemented in the
current JAX-RS model. In your scenarios above, no performance benefit
can be realized unless the application developer is aware of the issue
and programming specifically towards it. For slow input, you have to
read in chunks and continually return control back to the container.
For slow output, you need to chunk fairly between your output requests,
otherwise you have a different starvation problem with high load/slow
networks.
Are you familiar with Erlang and the YAWS benchmark? They can solve
this chunking problem easily, seemlessly, and without developer
knowledge because they use green threads on top of OS ones. Java
doesn't have this luxury. Even Jetty Continuations force you to program
in a certain way with their horrible use of exception throwing to change
program control flow.
> 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.
There is no imposition being done. If an OutputStream is injected, then
the request input and output is handled by one thread. If the app
developer doesn't inject an OutputStream, it doesn't have to.
> Marc and Stephan proposed balanced
> solutions that seem reasonable to me, even if they add a little more
> complexity from your point of view.
>
Its not a choice, or either/or for me. I want both. I want users to
have a simple intuitive model they are used to. I want to be able to do
fast prototypes writing as little code as possible, yet, I want the
model to be flexible enough so that I can refactor for performance.
Bill
P.S. ALl being said, this is an interesting thread. Thanks for
pointing out apis and discussions going on in the Restlet community.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com