I have completed the InputStream / OutputStream compatibility layer on
top of the lower level event-driven API. It actually proved quite a bit
more difficult that I initially thought.
I wanted to meet several primary design objectives:
(1) Ensure that HTTP connections can operate with a constant memory
footprint. Connections should attempt to grab largish but bounded
content buffers upon startup and terminate if unable to do so prior to
accepting the incoming request, thus giving the affected client a chance
to recover cleanly and retry the connection.
(2) HTTP connections can never go down with OutOfMemoryException after
having sent an 2xx response while streaming out the response content.
Content buffers can never expand.
(3) Individual workers can block temporarily if unable to consume
incoming content or if they produce more outgoing content than the
content buffer can hold
(4) Individual connections do not block the I/O reactor (and thus other
connections) when unable to deal with content volume.
As a consequence of these design objectives AsyncHttpService implies the
use of a worker thread per request / response exchange, but the worker
threads can be released before the response content is fully streamed
More testing and more polish is definitely needed but so far it appears
to hold up reasonably well for a first cut.
Here's the sample async HTTP server for an early feel of the new API