Hi Bill,
> And I'm saying that your model buys you nothing but the overhead of
> context switching.
I just want to exploit the potential of NIO. In some cases, users prefer to
gain scalability, limiting the number of threads, even if it increases the
latency (due to context switching). I don't say that this is desirable in
all situations.
> The email thread you are referring to above cannot be
> implemented in the current JAX-RS model.
Could you explain why? I think it is feasible.
> In your scenarios above, no performance benefit
> can be realized unless the application developer is aware of
> the issue and programming specifically towards it.
I think it can be supported if the entity is returned as an InputStream for
example.
> For slow input, you have to
> read in chunks and continually return control back to the container.
True.
> For slow output, you need to chunk fairly between your output
> requests, otherwise you have a different starvation problem
> with high load/slow networks.
True.
> 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.
I'm not very familiar with Erlang but Java can also have support for green
threads. BEA's JRockit support something close called thin threads.
http://dev2dev.bea.com/pub/a/2004/02/jrockit.html
You still have the call stack memory cost with several threads that you
can't save.
> Even Jetty Continuations force you to program
> in a certain way with their horrible use of exception
> throwing to change program control flow.
I'm looking forward to see what solution Servlet 3.0 EG comes up with, but I
think that our approach Restlet based on our Representation class is not
horrible at all :)
> 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.
The problem is that you ask the end-user to understand this complex problem
in order to make a conscious decision. It forces containers to support both
models, significantly complexifying the HTTP/IO stack, and prevents them
from uniformly managing threads, connections, sockets as it now depends on
whether a developer decided to use the outputstream. And how would the
container know that in advance? I maintain that this imposes the
thread-per-request model.
> 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.
OK
> P.S. ALl being said, this is an interesting thread. Thanks for
> pointing out apis and discussions going on in the Restlet community.
You're welcome. This is definitiely an interesting debate.
Best regards,
Jerome