[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-modperl
Subject:    Re: mod_perl survey results
From:       "Perrin Harkins" <perrin () elem ! com>
Date:       2008-11-12 16:31:55
Message-ID: 66887a3d0811120831i1471cbaav864c831c9b730dcb () mail ! gmail ! com
[Download RAW message or body]

On Tue, Nov 11, 2008 at 7:33 PM, Joel Bernstein <joel@fysh.org> wrote:
> 2008/11/11 Perrin Harkins <perrin@elem.com>:
>> On Tue, Nov 11, 2008 at 2:09 PM, Octavian Rasnita <orasnita@gmail.com> wrote:
>>> However, I've seen that many Catalyst developers prefer to use fastcgi and
>>> not mod_perl, because when using fastcgi, the applications can be restarted
>>> without restarting the whole web server.
>>
>> It's the same with mod_perl: you can restart your backend server
>> without touching the frontend proxy server.  It's possible that some
>> FastCGI implementations have a truly seamless way to do this though,
>> holding requests while the backend restarts.  I haven't played with it
>> enough to know.
>
> It's actually better than that. Typically in such a deployment you'd
> be using either a standalone FCGI process manager, or one built into
> the web application or web framework (the Catalyst FastCGI server has
> such a feature) then it's as simple as starting up a new version of
> the app, then shutting down the old one.
>
> All FastCGI child processes share a single unix domain socket on the
> filesystem, which is opened both by the child processes AND the
> webserver without O_EXCL, so the webserver continues to push requests
> down the socket, and whichever FastCGI process's accept() wins (this
> is up to the OS kernel) gets to serve the request.
>
> As long as you shut down the old version of the app after the new
> version is started, there's a completely seamless handover with total
> isolation from the webserver. The scheduling of request handling by a
> pool of backend appservers, again, is handled by the kernel rather
> than the webserver. This seems to me to be a good example of the Unix
> way of multiple processes handling one thing well.
>
> In the typical mod_perl deployment of a lightweight apache mod_proxy
> delegating requests to a mod_perl backend, I think the same thing
> could be achieved if both can be persuaded open the network socket
> between them without O_EXCL - then you can startup the new mod_perl
> appserver in tandem with the old, seamlessly the proxy will switch
> requests to the new one, and you can shutdown the old appserver. I'm
> not at all familiar with the apache internals though, so somebody
> else's comments on how possible this would be, are definitely
> appreciated.

Now _that's_ a great feature.  There are proxy servers that will do
this for mod_perl, but I'm not aware of a way to do it while using
apache as your frontend proxy.  Maybe mod_proxy_balancer could be made
to do it?

- Perrin
[prev in list] [next in list] [prev in thread] [next in thread]