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