On 14-Jun-08, at 10:04 AM, Edi Weitz wrote:
On Sat, 14 Jun 2008 07:21:05 +0200, Lars Rune Nøstdal <larsnostdal@gmail.com
wrote:
The goal of the current development obviously is to make Hunchentoot more flexible and at the same time to give its users more rope to hang themselves. In the end, it will still be a web server, though, with an eye on simplicity and backwards compatibility, it won't become an all singing and dancing General Problem Solver. I hope you won't be disappointed.
Edi, you've set the expectations :-)
(Just out of curiosity, are there general purpose web servers out there where one single request is not handled within one thread/process? I'm aware that Apache for example has a pretty sophisticated model of providing different ways of hooking into the request handling architecture. Still, I think, the thread that accepts the request will always be the one which is in charge of sending the reply and cleaning up, or am I wrong?)
My limited understanding of what they are doing is to separate socket handling from the thread that does the work (in increasingly sophisticated ways). So when a request comes a thread is assigned to it, handles the request and returns to the pool of available threads. The socket isn't necessarily closed (does HT handle keep-alive?) and is somehow named if it is kept open. If you tie this in with threads/ processes that are independent of the request-handling task, you can imagine one of these threads asking for a specific socket (or maybe a bunch of them) that is still open and shoving something down the socket/s, still not closing it/them. This also works with the new fangled event driven server stuff. Apache, jetty, tomcat, and a bunch of python, perl, and even a plugin for Rails (and <http://groups.google.com/group/symbolicweb
for lisp). There are problems with doing this using long lived HTTP
connections (e.g. firewalls), but people are doing it, so...
I didn't really take this too seriously until someone managed to comfortably handle many thousands (20000??) concurrent comet connections (the article went through what was done to achieve this number). It was nicely documented in an article, that, naturally, I can't find at the moment. I think this article might talking about the same thing, but it is certainly talking of 20000 connections, but it is mostly just reporting it:
http://cometdaily.com/2008/01/07/20000-reasons-that-comet-scales/.
This is possible useful:
<http://ajaxexperience.techtarget.com/assets/documents/Carter_Michael_Scalabl...
Cheers, Bob
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel