help with a multi process http server.

[Andre Garzia]

David,

my current idea is to keep everything in 100% transcript with maybe  
some shell() calls. What I have right now is:
* An 100% transcript based webserver.
* A lot of CGI libraries and utilities.
* an experimental FastCGI Daemon written in transcript.

That blog post is very interesting and I too follow some ideas  
outlined in there. The only thing I am trying to solve is the denial  
of service problem during blocking calls. Even with FastCGI we do  
have such trouble. None of my web apps running under FastCGI can  
contain a single blocking call for even if a smal "wait 10 ticks"  
happen inside the app, the whole engine will block.

Thats why I (and others) recommend using plain old CGI for real world  
scenarios. Spawning one rev instance per request is not that bad, the  
interpreter is small enough and starts very fast.

As for your question on putting RevHTTP behind a good proxy, the  
problem again is blocking calls. If the engine is busy figuring out  
some lenghty calculation and the master proxy tries to send something  
more, then we're pretty much in denial of service.

any clue?

Andre

On Jan 25, 2007, at 11:57 AM, David Bovill wrote:

> Along hose lines Andre - why not just put the Rev HTTP servers  
> behind a
> mature http proxy as they do in the Java and Zope world? Here is an  
> article:
>
>
> http://www.vmunix.com/mark/blog/archives/2006/01/02/fastcgi-scgi- 
> and-apache-background-and-future
>
> And a quote from the above:
>
> What Java and Zope app servers do (for the unfamiliar) is run their  
> own
>> solid HTTP servers that do intelligent URL parsing/generation for  
>> you to
>> make sticking them behind a HTTP proxy (like Apache's mod_proxy,  
>> or Squid,
>> or whatever) at an arbitrary point in the URI a piece of cake.  
>> Typically you
>> redirect some URL's traffic (a virtual host, subdirectory, etc.)  
>> off to the
>> dedicated app server the same way a proxy server sits between your  
>> web
>> browser and the web server. It works just like directing requests  
>> off to a
>> Handler in Apache, except the request is actually sent off to  
>> another HTTP
>> server instead of handed off to a module or CGI script. And of  
>> course the
>> reply comes back as a HTTP object that's sent back to the originator.
>> There's a bunch of reasons why doing this with HTTP instead of CGI  
>> is a
>> really nice approach. One is that setting up these app servers  
>> becomes
>> pretty simple for sysadmins and doing the configs on the upstream
>> webserver/proxy is IDENTICAL no matter what kind of downstream app  
>> server
>> you're talking to. That's reduces errors. It's flexible, too,  
>> allowing you
>> start up an app server instance (which, of course, acts like a web  
>> server)
>> on a port, run it as whatever system user you want, jail it, zone it,
>> firewall it, whatever, and then you send HTTP requests to the  
>> thing. You can
>> go straight to the app server in your web browser to debug stuff.  
>> Since it's
>> HTTP we already have a full suite of tools that can do intelligent  
>> things
>> with the protocol. Firewalls, load balancers, proxies, and so on.  
>> There's a
>> huge market of mature "HTTP brokers" both free and commercial,  
>> including
>> Apache itself (mod_proxy, which can be hooked into rewrites).