|
AJ Coon
ajcoon at gmail.com
Thu Feb 21 00:40:32 EST 2008
Hi Graham, Actually I have a separate module called Path that handles the sys.pathtomfoolery. 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). 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... Thanks, -aj 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 > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20080221/0353a64d/attachment.html
|