help with a multi process http server.

[David Bovill]

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





On 23/01/07, Jan Schenkel <janschenkel at yahoo.com> wrote:
>
> --- Andre Garzia <soapdog at mac.com> wrote:
> > Hello Folks,
> >
> > I am here experimenting with a new approach to
> > building revolution
> > based servers. We've been asking for threads or
> > forks for a while but
> > until the day of such implementation comes, we need
> > to use what we
> > can. One other language I always liked (to the point
> > that we created
> > a whole company around it some years ago) was REBOL.
> > I remember from
> > the blogosphere that someone did a REBOL based
> > webserver with some
> > nice benchmarks, I decided to check it out because
> > last I remembered,
> > REBOL was also a single thread language. After
> > checking many sites, I
> > discovered that they along with other people around
> > are using a
> > process pool and a scheduler that handles the
> > connections and
> > redirect them to the next free process on the pool.
> >
> > I decided to take the same approach, I made a
> > tweeked version of my
> > RevHTTP server that can be launched from a shell()
> > call so that I can
> > create a scheduler that can launch some number of
> > processes to make
> > the pool. I created a simple communicating scheme
> > using wget to make
> > little semaphores so that each server instance can
> > tell the scheduler
> > where it is busy or free. So far, so good but
> > there's one problem.
> >
> > Suppose the scheduler is running 8080 and each
> > server instance in the
> > pool is running from 8081 onwards. When the client
> > connects to 8080,
> > the scheduler sends back a redirection response so
> > that the client
> > refreshes to a different port (of a free instance in
> > the pool). The
> > problem is that a http client such as a browser will
> > then request
> > favico and all the links in the html from the same
> > port for it re-
> > uses data from the connection that yielded that
> > result to fill
> > missing data in the URL. For example, if you make a
> > link that goes
> > to /newpage.html, then the server will make it
> > http://yourserver/
> > newpage.html. If I answered from port 8081, all
> > links in the page
> > will "inherit" that port and I want all the
> > connections to come to
> > the scheduler running on a different port.
> >
> > One approach to solve this is to parse all the
> > response and change
> > all the html responses to include the correct URLs.
> > This is very
> > boring and slow for we must cope with href, src,
> > link, rel and all
> > kinds of css includes and stuff. What I hoped to
> > find was some HTTP
> > header field that would tell like: "hey this server
> > is acutally
> > running at port bla bla bla" such as:
> >
> > host: localhost:8080
> >
> > despite the fact that that answer came thru 8081.
> > This way the whole
> > thing would work and maybe we would have a a web
> > server built with
> > Rev that could see some real world use...
> >
> > Anyone has two cents?
> >
> > Andre
> >
>
> Hi Andre et al,
>
> During one of my similar experiments, I ended up with
> an http server that didn't do any of the serving
> itself, but acted as a router between the client
> computer and the server apps.
> The server apps ran on ports that were blocked from
> outside access, instead of using redirects. The
> housekeeping can be done fairly easily, and you can
> use a chunking approach along with asynchronous write
> to socket commands.
> However, rapidly refreshing the browser can result in
> a serious overload of the routing/scheduling app so
> you'll want to add the necessary logic to cancel
> requests that are being processed by the server apps.
>
> Just my two eurocents,
>
> Jan.
>
> Quartam Reports for Revolution
> <http://www.quartam.com>
>
> =====
> "As we grow older, we grow both wiser and more foolish at the same
> time."  (La Rochefoucauld)
>
>
>
>
> ____________________________________________________________________________________
> Bored stiff? Loosen up...
> Download and play hundreds of games for free on Yahoo! Games.
> http://games.yahoo.com/games/front
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>