[hunchentoot-devel] Re: Current development

[Bob Hutchison]

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

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_ScalableComet.pdf 
 >

Cheers,
Bob


>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel