<br><div class="gmail_quote">On Wed, Mar 4, 2009 at 12:40 AM, Grzegorz Nosek <span dir="ltr"><<a href="mailto:grzegorz.nosek@gmail.com">grzegorz.nosek@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On wto, mar 03, 2009 at 08:09:12 -0800, Roger Hoover wrote:<br>
> For dynamically spawned processes, if someone were willing to write an nginx<br>
> module to call supervisord's XML-RPC api, we'd have a complete,<br>
> language-agnostic replacement solution for mod_fastcgi.<br>
<br>
</div>XMLRPC sounds evil ;) My checklist for required features looks like<br>
below, how far is supervisord from meeting that?</blockquote><div><br>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.</div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
- killing idle processes after some timeout (with a configurable<br>
signal, preferably)</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
- static pool size management (keep 5 of those running at all times)</blockquote><div><br>This is already available in supervisord<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
- dynamic pool size management (keep 1-5 running depending on load;<br>
this will require congestion notifications from the web server, like<br>
you said)</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
- process status notifications ("foo failed to run, what now?", with<br>
some mildly intelligent retry logic) -- I need to alert an external<br>
entity somehow.</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
- easily generated configuration file</blockquote><div><br>I think the config is pretty simple but I'll let you be the judge (<a href="http://supervisord.org/manual/current/configuration.html">http://supervisord.org/manual/current/configuration.html</a>). I generate supervisord configs dynamically in my current company using Perl Template Toolkit.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
If supervisord can do that, I'd be willing to write an Nginx module to<br>
interface with that, sometime in this millenium.<br>
<br>
Best regards,<br>
<font color="#888888"> Grzegorz Nosek<br>
<br>
</font></blockquote></div><br>