|
Graham Dumpleton
graham.dumpleton at gmail.com
Thu Feb 21 00:49:39 EST 2008
On 21/02/2008, AJ Coon <ajcoon at gmail.com> wrote: > Hi Graham, > > Actually I have a separate module called Path that handles the sys.path > tomfoolery. It basically reads in a text file where each line is a path I > want to append to sys.path, and does the appending for me. In that file I > do have the path to the module directory listed explicitly. I've removed > that and it still seems to be broken to the same extent (not worse). Yay. > > > Something else I just noticed...watching the logs as I replicate this > condition, I'm logging sys.path explicitly at the top of my handlerA module, > right after I import mod_python stuff and my Path module. What's > interesting is that it doesn't always log there. It's as if some of the > requests being handled re-use the same handler instance- which is great > because I'm sure this is giving me the performance boost that I want from > mod_python. (That should answer your question about "why mod_python". > Basically, CGI is too slow for what I need to handle). No it doesn't really answer my question. The mod_python module isn't the only module for Apache/Python stuff anymore. If your code wasn't heavily bound to mod_python specific features and could be modified to be a WSGI application you could use mod_wsgi instead. I am more confident in mod_wsgi not having problems with multiple VirtualHost that mod_python some times seems to have. > So the first time a new handlerA instance is created after the first > handlerB instance is created, the sys.path that gets logged for handlerA > shows me what I know handlerB is setting it to. The odd thing is, it > doesn't go both ways. I can invoke one or the other first after an apache > restart, the sequence isn't important. handlerA is the only one that seems > to suffer this fate. > > I tried to modify my VirtualHost configurations to use the .testhandler > thing but it didn't work. I'm not sure if you saw, but I'm using SetHandler > mod_python and then PythonHandler handlerA. I tried changing it to > SetHandler mod_python.testhandler but then that broke everything. I started > getting 404's. Is that expected? I wouldn't think so... I said to use: PythonHandler mod_python.testhandler not use SetHandler. I want you to replace your handler with this test handler. Have you dumped out mod_python.apache.interpreter yet and seen whether it is correct for each application? Graham > On Thu, Feb 21, 2008 at 12:25 AM, Graham Dumpleton > <graham.dumpleton at gmail.com> wrote: > > > > On 21/02/2008, AJ Coon <ajcoon at gmail.com> wrote: > > > Hi Graham, > > > > > > > > I wonder if this is a useful piece of information. I just noticed this > in > > > my logs: > > > > > > [Wed Feb 20 23:02:46 2008] [warn] mod_python (pid=29597, > > > interpreter='InterpB'): Module directory listed in "sys.path". This may > > > cause problems. Please check code. File being imported is > > > "/var/handlerB/www/handlerB_root/ProjectModule.py". > > > > > > I'm not sure I understand what it's complaining about? > > > > The new module importer underlaying import_module() and as also used > > by Python*Handler tries to keep mod_python module importer path > > separate from sys.path. This is because an overlap can cause problems > > with modules load duplicate times. You must be explicitly adding the > > document directory to sys.path in your script, which you shouldn't do. > > > > Can you show first part of script where you set sys.path. > > > > Graham > > > > > > > > > > > > > > -aj > > > > > > > > > > > > > > > On Wed, Feb 20, 2008 at 9:41 PM, Graham Dumpleton > > > <graham.dumpleton at gmail.com> wrote: > > > > > > > > > > > On 21/02/2008, AJ Coon <ajcoon at gmail.com> wrote: > > > > > > > > > Hi Graham, > > > > > > > > > > I'm not using PythonPath anywhere, though my handlers both make > > > > > sys.path.append() calls to add various library paths needed by each. > > > > > Inconveniently, each of these handlers use different versions of > some of > > > the > > > > > same libraries. It's a bit of a mess, but this all worked fine on > > > 3.1.3. > > > > > Now that I upgraded to 3.3.1 (and changed nothing else), it's > broken. > > > > > Rolling back seems the obvious choice, but I think what I'm trying > to do > > > > > *is* do-able, no? > > > > > > > > As per the documentation I pointed out, try setting: > > > > > > > > PythonOption mod_python.legacy.importer name > > > > > > > > this will restore the old module importer functionality. If it still > > > > doesn't work, possibly something in Apache configuration causing > > > > issues instead. > > > > > > > > In principle I can't see a problem with what you are trying to do, > > > > although see comments below. > > > > > > > > > > > > > As you requested, I have included my configuration below. I'm just > > > > > developing on a workstation and DNS is managed by /etc/hosts, hence > the > > > > > .localdomain host names. Without further adieu: > > > > > > > > Do those names map to distinct IP addresses or the same? > > > > > > > > In Apache documentation it doesn't recommend that you use FQDN in > > > > VirtualHost argument, but an IP address. Ie., in: > > > > > > > > > > > > http://httpd.apache.org/docs/2.2/mod/core.html#virtualhost > > > > > > > > It says: > > > > > > > > """A fully qualified domain name for the IP address of the virtual > > > > host (not recommended)""" > > > > > > > > The ServerName within the VirtualHost is what actually distinguishes > > > > them if using name based lookup against the same IP address. > > > > > > > > If using IPs or names rather than just *:80 then NameVirtualHost isn't > > > > required, but there have been cases where lack of NameVirtualHost in > > > > Apache configuration has caused mod_python to somehow merge sites when > > > > it shouldn't have been. Not know whether this is a bug in mod_python > > > > or not as when people got it working by adding NameVirtualHost, they > > > > were then interested in helping to debug the underlying problem. > > > > > > > > > > > > > aj at aj-5150:~$ cat /var/handlerA/www/.htaccess > > > > > PythonInterpreter InterpA > > > > > Options -Indexes > > > > > > > > > > aj at aj-5150:~$ cat /var/handlerB/www/.htaccess > > > > > PythonInterpreter InterpB > > > > > Options -Indexes > > > > > > > > Have you confirmed that the .htaccess files are in fact being > > > > consulted. You can do this by introducing a syntax error in them. Ie., > > > > add a line consisting of 'CRAP'. If when making request you then get a > > > > 500 error they are being consulted. The lack of an AllowOverride for > > > > the directories suggests they may not even be getting consulted and so > > > > the PythonInterpreter directives may not be getting applied. This may > > > > be combining with NameVirtualHost issues to end up with stuff running > > > > in same interpreter. > > > > > > > > You can work out which interpreter code is running in by printing out > > > > 'apache.interpreter' from mod_python module. > > > > > > > > Graham > > > > > > > > > > > > > >
|