On 8/20/09 1:24 AM, Mike Naberezny wrote: > Hi Roger, > > Roger Hoover wrote: >> I submitted a patch on Sunday. I just wanted to check if it got caught >> by a spam filter or if you guys didn't get a chance to look at it yet. > > We're sorry for the delay in responding. We did receive your patch. > >> Since then, I thought of one more idea to improve it and wanted to get >> your feedback. The way the patch works now is that a reference count is >> keep at the FastCGIProcessGroup level and when each fcgi subprocess in >> spawned and reaped, the increments or decrements the reference count. >> When the count hits zero, the socket is closed and when it goes from >> zero to one, it gets created again. >> >> The downside to this scheme is that if you restart an fcgi process >> group, there will be a period of time where the socket is down, which >> can cause client to to get errors during that time. The idea I had is >> that we really only need to tear down the socket when the group config >> is changed during a reload. I believe that this always happens though a >> called to the stopProcessGroup() method in the RPC interface. > > That is correct. > >> If so, we >> can have that method trigger a callback on the process group (something >> like ProcessGroup.stop_requested()). The base class does not need to do >> anything in that method but the FastCGIProcessGroup can set a flag that >> shutdown has been signaled and will close the fcgi socket when that flag >> is set and the reference count hits zero. >> >> If you agree with that concept, that should be a pretty simple change >> and I can submit a new patch. > > This sounds fine to me. Thanks!
Me too, - C > > Regards, > Mike > _______________________________________________ Supervisor-users mailing list [email protected] http://lists.supervisord.org/mailman/listinfo/supervisor-users
