Bob Hutchison wrote:
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...
Just a quick note that reducing the timeout of the comet-response (the empty one) works in these cases. I've confirmed this with more than one corporate firewall to the surprise of people expecting any networked application in similar style of something SW'ish to fail. :)
... I might add some heuristics that does some automatic adjusting and detecting on "boot-up time" for the comet timeout later ...