On Aug 9, 12:24 pm, "programmer.py" <[EMAIL PROTECTED]> wrote: > If you use mod_wsgi, like me, I'm not sure if you can get your changes > noticed without reloading apache.
If you are using 'daemon' mode of mod_wsgi you don't necessarily have to restart the whole of Apache for your changes to be picked up. What you need to do though depends a bit on your configuration. If you are using a single daemon process with many threads for the application, then you can embed a page in your application (password protected hopefully), that sends a signal to itself. Ie., import signal import os os.kill(os.getpid(), signal.SIGINT) This will cause the daemon process your application is in to shutdown. The Apache process supervisor will then automatically restart your process ready for subsequent requests. On the restart it will pick up your new code. This way you can control a reload from your application itself. You could feasibly even have a thread which goes around looking to see if file timestamps have changed occasionally and trigger a restart if they have. You can also send a signal from an external application, but problem there is identifying which process to send the signal. If you are running the daemon process(es) as a distinct user/group to Apache and each application is running as different user then you could just look for the Apache (httpd) processes owned by you, as opposed to Apache user, and send them all signals. This latter approach is probably what shared web hosting sites would be likely to provide if they pick up on mod_wsgi for Python hosting as each users applications would run as the user and so easy to apply. Thus they can trigger the restart from their control panel. If you are using 'embedded' mode of mod_wsgi so as to squeeze the most performance out of Apache, then you can't use the above approach. The most reliable way of having code reloaded in this case is to restart Apache. That said, mod_wsgi does support an optional 'Interpreter' reload mechanism that can be used in either 'daemon' mode or 'embedded' mode. That is, when the main WSGI script file is changed/touched, then the Python sub interpreter corresponding to the application will be destroyed and a new Python sub interpreter created within the same running process. The application will then be reloaded in the new Python sub interpreter. Although 'Interpreter' reloading is a good idea in theory, in practice it will not always work. This isn't because of mod_wsgi or Python, but because there are various third party Python C extension modules out there that haven't been written properly so as to be able to cope with Python sub interpreters being destroyed and recreated within the one process. More details on this can be found at: http://code.google.com/p/modwsgi/issues/detail?id=12 Another option being looked at for a future version of mod_wsgi is 'Process' reloading. This would only work with 'daemon' mode, but would cause an automatic restart of a daemon process when the WSGI script file has been changed. Getting this functionality working correctly is non trivial though and would result in some additional overheads. FWIW. The OP has started up numerous discussions on various groups complaining about poor Python web hosting, yet based on what they are saying they don't want to pay anything but the absolute minimum they can get away with. So, a specialised Python web hosting company charges more than what they want to pay. Since true commodity web hosting in their price range is tailored to PHP and wants to achieve site densities that would preclude true long running processes, I don't believe they will find an acceptable solution at this point. I recently commented on some of these problems with using mod_wsgi for commodity web hosting on my blog and some of the comments I make there are probably relevant to the discussion. http://blog.dscpl.com.au/2007/07/commodity-shared-hosting-and-modwsgi.html Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
