<br><br><div class="gmail_quote">On Thu, Oct 22, 2009 at 12:32 PM, Grzegorz Nosek <span dir="ltr"><<a href="mailto:root@localdomain.pl">root@localdomain.pl</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 czw, paź 22, 2009 at 11:01:36 -0700, Roger Hoover wrote:<br>
> For a config like this,<br>
><br>
> [fcgi-program:test]<br>
> command=/foo//bar/test.fcgi<br>
> socket=unix:///var/run/fcgi/test.socket<br>
> process_name=foo_%(process_num)s<br>
> numprocs=2<br>
><br>
> [program:test2]<br>
> command=/foo//bar/<a href="http://test.pl" target="_blank">test.pl</a><br>
> process_name=foo_%(process_num)s<br>
> numprocs=2<br>
><br>
> There has to be a way to disambiguate between test:foo_0 and test2:foo_0.<br>
<br>
</div>Right. I was wondering whether the names had to be globally unique. The<br>
config above means they don't have to.<br>
<div class="im"><br>
> This issue seems to be that nginx will not allow backend names to contain<br>
> ":"? Is there no way to translate between a name used in nginx and the name<br>
> used in supervisord? Maybe the nginx backend name could be "test__foo_0"<br>
> which gets mapped to "test:foo_0" when doing supervisord XMLRPC calls?<br>
<br>
</div>It works like that out of the box? If so, that's great news and it means<br>
our module can manage every possible program.<br></blockquote><div><br>I was thinking that the nginx module would keep this mapping. For each fcgi pool, it would have an nginx backend name (test__foo_) and a supervisor name (test:foo_). When the module is doing routing stuff, it would use backend name but when it's spawning and reaping processes, it would use the supervisor name. Is something like this doable?<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>
So, can we simply name the upstream 'test__foo_'? (it should be fine as<br>
far as Nginx is concerned and will manage programs called test__foo_0,<br>
test__foo_1 etc.)<br>
<div class="im"><br>
> > BTW, and straying a bit from the original topic, it's my personal pet<br>
> > peeve -- why did FastCGI do the right thing and standardise on receiving<br>
> > the listening socket from high above but no application server using<br>
> > HTTP I've seen can do it? It solves so many problems cleanly.<br>
><br>
> Hmm...great question. I've never looked at Apache internals but assumed it<br>
> worked that way.<br>
<br>
</div>Apache does share the listening sockets between its processes, if that's<br>
what you mean. It's that it cannot inherit the socket from e.g.<br>
supervisord.<br>
<br>
The problem is bigger with all the fancy dedicated application servers a'la<br>
Mongrel or Thin or whatever is the cool thing to run Rails on now are<br>
_designed_ to run behind a load balancer, even when it's totally<br>
unneccesary (all the backend servers on a single machine). I guess I<br>
have to start a crusade and send patches to all these guys to implement<br>
listening on an inherited socket.<br></blockquote><div><br>Oh, I see what you mean. I'm with you!<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>
Anyway, it's way off topic now.<br>
<br>
Best regards,<br>
<font color="#888888"> Grzegorz Nosek<br>
</font></blockquote></div><br>