2009/3/21 Nimrod A. Abing <[email protected]>: > > On Sat, Mar 21, 2009 at 5:13 PM, Graham Dumpleton > <[email protected]> wrote: >> >> 2009/3/21 Nimrod A. Abing <[email protected]>: >>> >>> On Sat, Mar 21, 2009 at 4:09 PM, Florian Bösch <[email protected]> wrote: >>>> >>>> On Mar 20, 10:23 pm, Graham Dumpleton <[email protected]> >>>> wrote: >>>>> No it doesn't. You have also made other statements which show you are >>>>> making wrong assumptions about how it works. >>>> >>>> If I issue an os.kill(os.getpid(), signal.SIGINT) the ongoing request >>>> is still served by this process. In the context of wanting a request >>>> be served from the *newly started* process this is quite usless, which >>>> Is why I suggested an alternative configurable behavior. >>> >>> I had the exact same problems described by the OP while using the >>> monitor.py. At any given time I could make changes to several files. >>> Some of the changes may be dependent on each other and cause problems >>> if I forget and issue :w instead of :wa from my editor. >> >> If you don't write all the changes, you are going to have a problem >> not matter what mechanism you use as you are going to have an >> inconsistent code base. That is a user problem, not a problem with the >> monitor script. > > I now realize that if I did a :w instead of :wa I do notice that and > issue a :wa. In which case the updated code is reloaded by the monitor > script anyway and the possible problems caused by incomplete writes go > away. > >> As explained in prior mail, because mod_wsgi does lazy loading of >> application, it doesn't matter that daemon shuts down on first edit, >> as it will not reload the WSGI application until the next request you >> trigger. If you haven't written all your code before making next >> request, that is your own problem. > > On a testing server that I have, this has caused me a lot of grief > because the FTP connection I use can cause a partial upload. What I > did was increase the time between file modification time checks in the > monitor.
The presumption in this whole discussion is that you are working on a development server. That is, presumed that it is only you who are working on the code and that only you would be making requests against the server. In this context, changing the time between checks wouldn't do anything as all it is doing is increasing the size of the window for how long to may take daemon process to detect change, shut down and go into the unused and uninitialised idle state. Once in that uninitialised idle state, presumably there are no request until you make one. If there was an FTP upload problem, presumably you have a way of knowing and reuploading the files again. Once you are then happy, you make the request and only then does WSGI application load all the code. Thus, don't see how changing the delay time helps at all. If it is the case that you are actually making changes on a live system used by other people, then you should not be using the monitoring mechanism and instead should be relying on a scheme where WSGI script file is in effect unchanging, code wise. Once you upload all your changes, then you reupload or touch the WSGI script file to explicitly trigger the daemon process restart. That way you will not have a problem with some third party making a request and causing application to reload when part way through changes being uploaded. >>> I was looking >>> for an alternative way of triggering a reload and the SIGINT trick >>> inside a single-process daemon was the first thing I tried. I have >>> always wondered what happens when SIGINT is signalled to the daemon >>> process. 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. > > That's a relief. Also worth point out is that the daemon processes aren't receiving HTTP requests directly. Instead requests are proxied from Apache child server processes. This means that during a daemon process restart, remote clients can still connect, there requests will effectively be queued up with Apache child server processes, which will keep trying to reconnect to daemon process. When daemon process restarted, they will be successful and request will proceed. Thus, it should be transparent to remote client, unlike systems which use mod_proxy to a backend Python HTTP server. In those systems, when the backend Python HTTP server is being restarted, there is nothing to accept request so they will fail and remote client will see an error such as service unavailable, returned by the proxy. The only issue I know of with daemon process restarting is not with this monitoring system but with an Apache graceful restart and where remote client is using keep alive with multiple requests over same connection going to a WSGI application. Because Apache will keep around Apache child server process for life of keep alive connection, it can have a stale reference to daemon process and so may error in connecting. In practice have only ever seen this be a problem when doing benchmarking with -k (keepalive) and you do a graceful restart at the same time. In real systems, has never come up as multiple requests over a keep alive connection to a WSGI application isn't something that normally happens. >>> Apparently the Django view executes just >>> fine, I have code after os.kill() that does a redirect and it seems to >>> work. >>> >>> Anyway, +1 on having an alternative configurable behavior. Maybe a >>> "developer mode" where each request is handled by a newly spawned >>> daemon process and it could work in similar fashion in embedded mode. >>> This is regardless of whether or not code has changed. During >>> development, I don't really care about performance issues caused by >>> file system access or process creation overheads. >>> >>> This sort of behavior is no different from just using plain CGI but >>> the idea here is that you can set up your development server *exactly* >>> as you would for production with the exception that you can have a >>> configuration option that enables "always reload" behavior. That way >>> all you would have to do is copy over the configuration from >>> development server to production server, minus the "always reload" >>> switch. >> >> The current mechanisms do what is required, it is the understanding of >> how it works which is wrong. Nothing new is needed. The only case >> where you might want to do something different is the background task >> example I mentioned in prior message, and for which I indicate an >> alternative you could use. >> >> At the moment all I am seeing from original poster is speculation that >> it isn't going to work how they need it to and no actual indication >> that they have actually tried it and can show it has a problem. > > You're right. Theoretically it *could* cause problems but in practice, > from what I have experienced so far anyway, it's really no big deal > and the current methods of reloading are more than adequate. Correct, there are certain odd requirements where may be an issue, plus few other problems can arise in certain cases, but we are talking about a mechanism for use in a development server. What does it matter if it isn't perfect, all you need to do is reload the page again and it will generally right itself. This is about as good as you are going to get with Python. This isn't PHP where the application is thrown away at the end of every request. 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 -~----------~----~----~----~------~----~------~--~---
