2009/3/22 gert <[email protected]>: > Can you kill something that still has to return some really big > response ?
This point was already explained if you had paid attention to the descriptions given previously of how things worked. What was said was: >> Does it stop the process immediately, leaving code after the >> os.kill() call unexecuted? > > No, it performs an orderly shutdown of the daemon process, attempting > to wait for all current requests to finish before actually killing the > process. As a fail safe however, if the active requests take more than > the shutdown timeout, default of five seconds, then it will forcibly > kill off the process. Also have a look at the online documentation for 'shutdown-timeout' option for WSGIDaemonProcess directive in: http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess And yes this could be viewed as a limitation, but ultimately you do not have much of a choice. If you were to wait indefinitely then no requests would get served and things would block completely, once all the available daemon processes in that group had entered that waiting state. The behaviour as implemented is actually like a normal 'restart' or 'stop' of Apache. As mentioned in the documentation, Apache actually only waits three seconds when doing those forms of restart or shutdown, so am actually giving you slightly more than Apache does. In the case of a 'shutdown' the Apache timeout will actually trump you and kill off the request anyway, even if the daemon process five second timeout hadn't been reached. What it does mean is that if your application is handling requests which take a long time, you have to be careful about the use of options like 'maximum-requests'. This is because the regular restart of a daemon process could impact those long requests. Overall it is best to avoid 'maximum-requests' unless you really have to. If you can't avoid it because of creeping memory usage in an application, then try and segment out the long requests by delegating just those URLs to run in a daemon process group of its own and set different options for that daemon process such that less risk of those requests being impacted in some way. Daemon process groups do not have a graceful restart/shutdown equivalent as such a thing becomes problematic as far as overall memory usage. This is because you can't be sure what the maximum number of daemon processes can be, totally throwing out any certainty as to how much memory you need. This is one of the failings of embedded mode which failed to mention when running Python web applications in my recent blog. That is, if you use embedded mode and do a graceful restart, you can actually peek at more than maximum number of processes further screwing you up by running out of memory. Thus daemon process groups use a fixed maximum regardless and forcibly kills off processes when it has to. Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
