FCGI.pm ?

[Roger Hoover]

On Wed, Mar 4, 2009 at 12:40 AM, Grzegorz Nosek <grzegorz.nosek at gmail.com>wrote:

> On wto, mar 03, 2009 at 08:09:12 -0800, Roger Hoover wrote:
> > For dynamically spawned processes, if someone were willing to write an
> nginx
> > module to call supervisord's XML-RPC api, we'd have a complete,
> > language-agnostic replacement solution for mod_fastcgi.
>
> XMLRPC sounds evil ;) My checklist for required features looks like
> below, how far is supervisord from meeting that?


I'm not a huge XMLRPC fan either but Python makes it easy for the project
implementers.  I suppose some other data format such as JSON is possible if
there's a will.

>
>  - killing idle processes after some timeout (with a configurable
>   signal, preferably)


I think it's difficult to kill individual processes that have timed out when
a pool of processes are all listening on the same FCGI socket because nginx
would not know which process had accepted the request that timed out (unless
there is some mechanism in the FCGI protocol to do this).  However, the
entire process pool could be killed/restarted if that's the behavior you
desire.


>
>  - static pool size management (keep 5 of those running at all times)


This is already available in supervisord


>
>  - dynamic pool size management (keep 1-5 running depending on load;
>   this will require congestion notifications from the web server, like
>   you said)


Functionality was recently added to supervisord to modify it's configuration
dynamically through the XML-RPC api so this is matter of implementing the
load logic in an nginx plugin and making calls to supervisord to add and
subtract from the pool.


>
>  - process status notifications ("foo failed to run, what now?", with
>   some mildly intelligent retry logic) -- I need to alert an external
>   entity somehow.


Depends on what kind of failure.  If process foo exits with an unexpected
exit code, supervisord has an event listening API (a simple text protocol
listening on a pipe) that allows you to write an event handler in any
language to deal with those events.  However, if process foo fails in the
sense of returning a 500 status code or not returning any data at all, that
would have to be handled by nginx module.


>
>  - easily generated configuration file


I think the config is pretty simple but I'll let you be the judge (
http://supervisord.org/manual/current/configuration.html).  I generate
supervisord configs dynamically in my current company using Perl Template
Toolkit.


>
>
> If supervisord can do that, I'd be willing to write an Nginx module to
> interface with that, sometime in this millenium.
>
> Best regards,
>  Grzegorz Nosek
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20090304/782f4a49/attachment.html>