Hi Bruce, On Thu, Sep 23, 2010 at 1:41 PM, Bruce Frederiksen <dangy...@gmail.com>wrote:
> I'm new to supervisor and would like a capability that takes the > fcgi-program feature one more step. > > What I want is for supervisord to create a socket (like it does for > fcgi-program), but then also do the accept on it. Each time a connection > comes in, spawn the child process and hand-off the connection to the new > child. From that point forward, supervisord is not involved in the > communication between the connecting client and the spawned server. > Do you mean always spawn a new process per connection? If so, that's how CGI works so you should just use that instead of FCGI. If you mean dynamically spawning a limited number of FCGI processes on demand, then I think an nginx_plugin is the way to go. See A below. > > The reason I want this is to give the client control over how many server > processes are spawned. Supervisord would create the socket when it starts, > but not spawn any of these type of processes until connections come in. > This is a case where I am writing both the client and server, and the server > is only visible on the internal network. > > A. Does anybody know if something like this already exists? > Can what you need be accomplished with this nginx plugin? http://labs.frickle.com/nginx_ngx_supervisord/ I haven't actually tried it yet but it looks like you can configure it to spawn fcgi-programs on demand upstream backend { server 127.0.0.1:8000; server 127.0.0.1:8001; supervisord 127.0.0.1:9001 admin:super; fair; } server { location / { proxy_pass http://backend; } } > B. For those "in the know" on the internal architecture of supervisor, > what pointers do you have on how to implement this? > I think this would be pretty hard to do it in the supervisord process. You have to jump two hurdles. a) You'd have to figure out a reliable way to know when an FCGI socket needs to be cleaned up. If you search recent posts to this lists, you'll see that the currently implementation keeps a count of how many FCGI child processes there are and closes the socket when the count hits zero and creates it when the count goes above zero. I won't go into the details here as to why but this problem would have to be overcome if you want to create the socket before any FCGI children have been spawned. b) You can't do any blocking network calls so you'd have to plugin into the main select() loop. I'm not sure how hard or easy that will be. Then I think it would have to work something like this: you'd have to create the socket with the O_NONBLOCK flag set until the first connection comes and set it back to blocking before handing it off to the first child process. Keep calling accept() and checking for EWOULDBLOCK or EAGAIN until it's ready. Then you spawn the appropriate FCGI process to handle it. Again, I think your best bet is an nginx plugin. > > C. Is anybody else interested in something like this, and if so, what > would you like to see in it (no promises though). > > Thanks! > > -Bruce > > _______________________________________________ > Supervisor-users mailing list > Supervisor-users@lists.supervisord.org > http://lists.supervisord.org/mailman/listinfo/supervisor-users > >
_______________________________________________ Supervisor-users mailing list Supervisor-users@lists.supervisord.org http://lists.supervisord.org/mailman/listinfo/supervisor-users
