|
Graham Dumpleton
grahamd at dscpl.com.au
Mon Jul 18 19:51:46 EDT 2005
Kevin J. Smith wrote .. > > I am currently trying to run a number of mod_python applications on one > server but it is starting to be difficult to manage and was always clunky > to > implement. What are the ways to configure apache so that two mod_python > applications can run under one apache without running into each other? Have a look at the following directives for mod_python: PythonInterpreter PythonInterpPerDirective These allow you to assign a separate Python interpreter to each distinct application in slightly different ways. With each application running in a distinct interpreter, it is harder for them to intefere with each other. > There is also the > long-standing problem of having to restart apache when key modifications are > done to the code otherwise it does not properly re-import the module. > Therefore, the application owners have to be able to restart apache. The module importation system as implemented by mod_python has various shortcomings. It may perhaps help first to understand some of the issues with it a bit better if don't understand them already. For that, suggest reading: http://www.dscpl.com.au/articles/modpython-002.html http://www.dscpl.com.au/articles/modpython-003.html > Currently, if each project has a config file then the last PythonPath > directive trumps all previous, among other problems that we have worked > around and if they are running as virtual sites then they must stick to > unique directories as it is a flat namespace according to mod_python. Is > there a way to do virtual hosting of mod_python? That there is a flat namespace as you refer to it is a pain, although some on the list reckon it is quite reasonable, as it is the Python way of doing things. There has been slow movement on addressing the problems in the module importing system and the above articles are a part of that process. There has also been a bit of discussion on the mailing list recently about how it could actually work: http://www.modpython.org/pipermail/mod_python/2005-July/018642.html The closest you are going to get to a reasonable working solution at the moment is to perhaps use the Vampire package as a base for applications. This package provides a improved module importing system which solves the major problems in the existing system. When used properly, you don't get the namespace collision problems, and modifying code modules, even when it isn't a top level handler will still result in the changed module and anything which depends on it being reloaded. Your mileage as far as what you can get out of Vampire will vary. If you are adverse to using anything but the core mod_python system, then it is likely it will be totally unacceptable and you'll have to mostly put up with what you have. FWIW, you can find information on Vampire at: http://www.dscpl.com.au/projects/vampire Note that Vampire isn't a system where you are expected to do things the Vampire way. With a little bit of extra trickery, you could largely keep what you have as is with only minor tweaks. These sorts of tricks aren't necessarily in the documentation though, so if you are interested would need to know more about how your systems are setup and step you through what changes to make. Graham
|