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€ :-) > > cheers, > Roland >
Hi Roland, 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. How does that sound? Oleg > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
