On Fri, 2006-10-06 at 17:35 +0200, Roland Weber wrote:
> Hi Oleg,
> > Execution of HTTP requests still requires a worker thread per
> > connection. This limitation I intend to tackle next. The plan is to
> > provide an HTTP protocol layer based on the existing HttpCore API that
> > can handle an arbitrary number of connections with just a handful of
> > threads. There are several possible implementation strategies to choose
> > from. If anyone is interested in discussing the options before I get
> > down to hacking please let me know.
> I have taken a look at asyncweb earlier this week. They use a different
> style of parser for the message headers, so they can feed in data as it
> arrives. The parser elements then fire soem kind of event whenever a
> token as been parsed. I'm not sure whether that's what you have in mind.
> http://docs.safehaus.org/display/ASYNCWEB/Home >
> If you throw some ideas into the ring, I'll give you my 0.02€ :-)
Yes, something similar but not quite the same. I am thinking about
having an event driven architecture of some sort, but I certainly do not
want to go the same route asyncweb folks did with regards to memory
management. As far as I know asyncweb buffers content in memory and can
be prone to 'out of memory' conditions even when serving moderate
amounts of data under heavy load. In my humble opinion this is way worse
then dropping incoming connections due to the worker thread pool
depletion, because the former gives the clients a very clean and
reliable recovery mechanism, whereas the latter does not. Dropping the
connection due to the out of memory condition after having processed the
request while sending out the response is a complete insanity.
So, in my opinion there are several options we could pursue.
(1) Never ever block I/O in HTTP service. As a consequence always buffer
content in memory. This approach is flawed, but is relatively simple.
(2) Always block I/O in HTTP service when serving potentially large
entities in order to prevent session buffer overflow. Requires a worker
thread per large entity content stream.
(3) Do not use streams. Use callbacks for I/O events that take NIO
buffers as parameters.