RE: JSR311: Response isn't adequate

From: Jerome Louvel <>
Date: Wed, 12 Mar 2008 12:08:28 +0100

Hi Bill,

> There's no support for Comet-like callbacks? Especially for
> input. For output, there's no way to chunk fairly.

For output it would be possible as I explained, based on an inputstream. For
input, this is harder indeed, but this was not in the use case described by
our user ;-)

> Yeah, I saw marc's example and you're right. Modeling the
> entity as an
> InputStream would allow output chunking. Thanks. Cool! :)
> But there's still the problem of input chunking, no?

Right, this would require the worker thread to release itself while waiting
for more content to be available.

> Read up on the YAWS bench. Its interesting to read the analysis from
> both the proponents and opponents of the bench.

Here are pointers:

"Apache vs. Yaws"

"NIO not faster than IO, according to... TSS itself?"

"Worst Measurement Ever"

> I just have a feeling (hope) that the OS's and VMs will
> advance enough
> where blocking I/O and thread-per-request will just scale massively.
> Especially with 64-bit machines and ever increasing ram maybe it just
> doesn't matter?

I hope so as well, but I guess people will always try to save resources when
massive scalability needs to be obtained.

> I thought Jetty Continuations threw an exception on suspend? That's
> what I thought was horrible. Using exceptions to do control flow.

That was true of their initial API. I know they are in the processing of
refactoring this part to be more inline with upcoming Servlet 3.0 API.

> How would the container know in advance? This information is
> available at deployment time. If a method returns void and OutputStream
> is injected, then the container knows that the request thread is
> handling output.

If you don't expose the outputstream directly on the Response and always
inject, I guess it is indeed possible... but I still don't like the idea
from a design point of view mainly.

Best regards,