[hunchentoot-devel] Re: Current development

[Lars Rune Nøstdal]

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 at 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 ...

-- 
Lars Rune Nøstdal
http://nostdal.org/