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"
http://www.sics.se/~joe/apachevsyaws.html
"NIO not faster than IO, according to... TSS itself?"
http://www.theserverside.com/news/thread.tss?thread_id=48449
"Worst Measurement Ever"
http://mykakotopia.blogspot.com/2007/10/worst-measurement-ever.html
> 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,
Jerome