On Jan 5, 12:54 am, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > On Sun, 2009-01-04 at 06:19 -0800, zvoase wrote: > > On Jan 4, 11:10 am, Graham Dumpleton <graham.dumple...@gmail.com> > > wrote: > > > Not true, Apache doesn't necessarily wait for all current requests to > > > complete before shutting down child worker processes. For a non > > > graceful restart or shutdown, Apache will give the process about 3-4 > > > seconds to exit and if it doesn't exit then it will kill it. Thus if > > > there were active requests which take longer than that to complete, > > > then they will be interrupted. > > > > There is a bit more to it than this but exact details depend on which > > > hosting mechanism you are using in conjunction with Apache. > > > > Graham > > > But if we're doing a non-graceful restart, then we can say goodbye to > > *any* hopes of things finishing nicely. In this case, Apache is > > forcefully terminating a process; ideally a set-up where processes > > were being killed in the middle of their execution is not going to use > > asynchronous *anything*, and also will want to have all DB work going > > on in transactions; having an Apache which just keeps killing stuff is > > going to be dangerous for code no matter what. And it shouldn't be > > taking 4 seconds for the user to receive a request, so by the end of > > that time all work should be done. If something *needs* to be done > > asynchronously that's going to take more than several seconds, then it > > should probably be delegated to a daemon running separately from the > > web server. > > Your response here and in a couple of earlier mails are pointing you in > the right direction. You've arrived at the point where asynchronous > signals are not a good idea. The approach is to synchronously set up an > entry in your external queue system to process anything that is going to > take a long time. The signal processing is thus very short and the > long-term operations are in no way tied to webserver process lifecycles > or client wait times or anything. It's directly analogous to top-half / > bottom-half interrupt handlers in operating systems, for example. > > I don't see the requirement for extra signal infrastructure complexity > in anything you've written in this thread. All your examples seem much > better handled by dispatching to an external processing queue. > > Malcolm
Yeah, I suppose so :) Well thanks a lot everyone, you've helped make things a bit more clear, and this thread is also probably going to be useful for future reference for anyone who's thinking of bloating the signals framework ;-) Regards, Zack --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
