|
Graham Dumpleton
graham.dumpleton at gmail.com
Fri Jul 31 18:13:31 EDT 2009
You need to be careful of running mod_wsgi on same Apache as mod_python. This is because mod_python gets precedence over initialisating Python interpreter. This means some of the abilities of mod_wsgi which require affecting how Python interpreter is initialised will not work. The mod_python module also leaks memory into Apache parent process on a 'restart' of Apache and although mod_wsgi fixes that, you will still be affected by it because of mod_python having control. Other issues can come up with mod_python/Python not installed properly so that Python has shared library etc. Graham 2009/8/1 Orr, Steve <sorr at rightnow.com>: > Thank you very much!! Believe it or not, that was exactly the answer I was looking for. We have several hundred servers with mod_python installed and a BOFH who created his own rudimentary publisher/framework around it. He's also the code tree librarian and Linux RPM dweeb so now I have some ammo to convince him add mod_wsgi to the mix. Wish me luck. > > > Steve Orr > RightNow Technologies > sorr at rightnow.com > > -----Original Message----- > From: Graham Dumpleton [mailto:graham.dumpleton at gmail.com] > Sent: Thursday, July 30, 2009 5:01 PM > To: Orr, Steve > Cc: mod_python at modpython.org > Subject: Re: [mod_python] WSGI Behavioral differences: mod_python vs mod_wsgi > > 2009/7/31 Orr, Steve <sorr at rightnow.com>: >> Running Apache 2.2.4; mod_python 3.3.1; Python 2.4. >> >> >> >> Experiencing behavioral problems with WSGI on mod_python. I'm running the >> exact same code but mod_wsgi works and mod_python does not. >> >> Here's the code which is the same in 2 files: myapp.wsgi; and myapp.py. >> >> def application(environ, start_response): >> >> status = '200 OK' >> >> output = '<html><body>\n' >> >> tbl = """<table border="5">""" >> >> for k,v in environ.items(): >> >> tbl += "\n<tr><td>%s</td><td>%s</td></tr>" % (k,v) >> >> tbl += "\n</table>" >> >> curpath = environ.get('PATH_INFO', '/') >> >> if curpath == '/maintenance/': >> >> output += '<h1>Maintenance page</h1>' >> >> else: >> >> output += """<h1>Hell!! Oh... Whirled!</h1> >> >> <a href="/myapp/maintenance/" target="_blank">Maintenance</a> <br />\n""" >> >> output += """%(tbl)s\n</body></html>""" % locals() >> >> response_headers = [('Content-type', 'text/html'), >> >> ('Content-Length', str(len(output)))] >> >> start_response(status, response_headers) >> >> return [output] >> >> >> >> The mod_wsgi implementation "routes" to the link properly but the mod_python >> version does not. With other tests it seems like environ is not in sync when >> using mod_python. I tried single process mode Apache and experienced the >> same problem. >> >> >> >> For the mod_python handler I've tried the 2 known versions from: Nicholas >> Borko; and Eli Collins. Both exhibit the same behavior. >> >> >> >> Is there some secret Apache directive needed to force mod_python to sync up? >> Here's how Apache is setup: >> >> <VirtualHost modwsgi:80> >> >> ServerName modwsgi >> >> ServerAlias modwsgi.local >> >> DocumentRoot /home/hydra/docroot/modwsgi >> >> WSGIScriptAlias /myapp /home/hydra/modwsgi/myapp.wsgi >> >> <Directory /home/hydra/docroot/modwsgi> >> >> Order allow,deny >> >> Allow from all >> >> </Directory> >> >> <Directory /home/hydra/modwsgi> >> >> Order allow,deny >> >> Allow from all >> >> </Directory> >> >> </VirtualHost> >> >> >> >> <VirtualHost modpython:80> >> >> ServerName modpython >> >> ServerAlias modpython.local >> >> DocumentRoot /home/hydra/docroot/modwsgi >> >> ScriptAlias /myapp /home/hydra/modwsgi/ >> >> <Directory /home/hydra/docroot/modwsgi> >> >> Order allow,deny >> >> Allow from all >> >> </Directory> >> >> <Directory /home/hydra/modwsgi> >> >> SetHandler python-program >> >> PythonHandler wsgi_handler >> >> PythonOption WSGI.Application myapp::application >> >> Order allow,deny >> >> Allow from all >> >> </Directory> >> >> </VirtualHost> >> >> >> >> Is this a handler problem or a mod_python implementation problem? Or a >> problem with my understanding? >> >> >> >> What do you recommend? > > Not use mod_python. :-) > > SCRIPT_NAME/PATH_INFO is critical in WSGI applications for routing and > mod_python can't provide that information accurately because of the > way it hooks into Apache. As a result any WSGI adapter for mod_python > would generally have a option to override what SCRIPT_NAME should be > with PATH_INFO being recalculated appropriately. > > As to mod_wsgi, it hooks into Apache as a resource much like CGI does > and so SCRIPT_NAME/PATH_INFO will behave as for CGI scripts and will > thus be correct. > > Graham >
|