I have two sites configured just like the configuration below (except
with different ServerName directives and different
DJANGO_SETTINGS_MODULE variables. The trouble is that Django's cache
is confusing the two sites and is saying that one table from a project
doesn't exist in the other project's db when I try to access it! I
tried setting different PythonInterpreters, but it had no effect. It
seems if I don't use different PythonPath directives for my sites, the
cache gets confused. But if I do that, the settings don't work
correctly and the site won't load. What am I doing wrong?
My site's config looks like this:
<VirtualHost *>
ServerName sitename.com
ServerAdmin rokcl...@gmail.com
DocumentRoot /djangosites/project/
<Location "/">
SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE project.settings
PythonPath "['/djangosites/'] + sys.path"
PythonDebug Off
</Location>
<Location "/images">
SetHandler None
</Location>
<Location "/js">
SetHandler None
</Location>
<Location "/flash">
SetHandler None
</Location>
<Location "/admin-media">
SetHandler None
</Location>
ErrorLog /var/log/apache2/sitename.com-error.log
# Possible values include: debug, info, notice, warn, error,
crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/sitename.com-access.log combined
ServerSignature Off
</VirtualHost>
> cache gets confused. But if I do that, the settings don't work
> correctly and the site won't load. What am I doing wrong?
you need a pythonInterpretor line in each Location with a different
name. It is in the documentation
--
regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
Not true if each is in its own VirtualHost as the default behaviour of
mod_python is to give each VirtualHost its own sub interpreter. You
should only need to set PythonInterpreter if you were running two
Django instances within the same VirtualHost at different mount
points.
For completeness, it would help if OP posted both VirtualHost
configurations side by side in the same message, so one can see
properly the PythonPath setting for each and the
DJANGO_SETTINGS_MODULE setting.
BTW, if using recent mod_python, to confirm that distinct Python sub
interpreters are being used one can use:
from mod_python import apache
apache.log_error("INTERPRETER %s" % apache.interpreter)
Then check the Apache error log file.
I would also suggest printing the value of sys.path to make sure it is
what you expect.
More importantly, when you say "Django's cache is confusing the two
sites and is saying that one table from a project doesn't exist in the
other project's db", can you post the actual full message you are
getting, and state where you are getting it. If it has a traceback,
also include the traceback.
Graham
Are you using the site-wide cache, and did you set your
CACHE_MIDDLEWARE_KEY_PREFIX? See that setting under
http://www.djangoproject.com/documentation/cache/#the-per-site-cache.
If you're not using caching site-wide, explain more about how you're
using caching and how it's getting confused.
Cheers,
deryck
--
Deryck Hodge
Lead Developer, Product Development
Washington Post.Newsweek Interactive
AGDWeb is an app in a totally separate project under the same
PythonPath. It has a separate settings file.
I am not using any Django cache, I am referring to some sort of
internal caching that mod_python is doing.
The settings file looks like this
<VirtualHost *>
ServerName beta.atlantaicecompany.com
ServerAdmin rokclim...@gmail.com
DocumentRoot /djangosites/atlantaice/
<Location "/">
SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE atlantaice.settings
PythonPath "['/djangosites/'] + sys.path"
PythonDebug Off
</Location>
<Location "/images">
SetHandler None
</Location>
<Location "/js">
SetHandler None
</Location>
<Location "/flash">
SetHandler None
</Location>
<Location "/admin-media">
SetHandler None
</Location>
ErrorLog /var/log/apache2/beta.atlantaicecompany.com-error.log
# Possible values include: debug, info, notice, warn, error,
crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/beta.atlantaicecompany.com-
access.log combined
ServerSignature Off
</VirtualHost>
and
<VirtualHost *>
ServerName agdweb.gtagd.org
ServerAdmin rokclim...@gmail.com
DocumentRoot /djangosites/AGD/
<Location "/">
SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE AGD.settings
PythonPath "['/djangosites/'] + sys.path"
PythonDebug Off
</Location>
<Location "/site-media">
SetHandler None
</Location>
<Location "/admin-media">
SetHandler None
</Location>
ErrorLog /var/log/apache2/agdweb.gtagd.org-error.log
# Possible values include: debug, info, notice, warn, error,
crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/agdweb.gtagd.org-access.log
combined
ServerSignature Off
</VirtualHost>
On Jun 21, 5:45 am, Graham Dumpleton <Graham.Dumple...@gmail.com>
wrote:
On Jun 21, 9:39 am, "rokclim...@gmail.com" <rokclim...@gmail.com>
wrote:
> Error can be seen herehttp://beta.atlantaicecompany.com/
atlantaice.urls
If the details in the error page are to be believed, it would look
like one of the URL mapping rules is referencing the other site.
I really wish the Django error page would show the interpreter name
when using mod_python. I guess another suggestion I should create a
ticket for when I can catch up with my list of things to do.. :-)
Graham
On Jun 21, 11:39 pm, "rokclim...@gmail.com" <rokclim...@gmail.com>
wrote:
> Error can be seen herehttp://beta.atlantaicecompany.com/
>
> AGDWeb is an app in a totally separate project under the same
> PythonPath. It has a separate settings file.
>
> I am not using any Django cache, I am referring to some sort of
> internal caching thatmod_pythonis doing.
> >mod_pythonis to give each VirtualHost its own sub interpreter. You
> > should only need to set PythonInterpreter if you were running two
> > Django instances within the same VirtualHost at different mount
> > points.
>
> > For completeness, it would help if OP posted both VirtualHost
> > configurations side by side in the same message, so one can see
> > properly the PythonPath setting for each and the
> > DJANGO_SETTINGS_MODULE setting.
>
> > BTW, if using recentmod_python, to confirm that distinct Python sub
> > interpreters are being used one can use:
>
> > frommod_pythonimport apache
[Thu Jun 21 20:00:23 2007] [error] [client 209.155.235.13]
PythonHandler django.core.handlers.modpython: File "/djangosites/
atlantaice/settings.py", line 3, in ?\n
apache.log_error("INTERPRETER %s" % apache.interpreter)
[Thu Jun 21 20:00:23 2007] [error] [client 209.155.235.13]
PythonHandler django.core.handlers.modpython: AttributeError: 'module'
object has no attribute 'interpreter'
atlantaice.urls doesn't reference AGDWeb in any way.
urlpatterns = patterns('',
(r'^$', 'atlantaice.web.views.homepage'),
(r'^alliedpartners/$', 'atlantaice.web.views.allied_partners'),
(r'^contact/$', 'atlantaice.web.views.contact'),
(r'^contact/confirm/$', 'atlantaice.web.views.contact_confirm'),
(r'^emergency/$', 'atlantaice.web.views.emergency'),
(r'^employmentopp/$', 'atlantaice.web.views.list_jobs'),
(r'^employmentopp/(?P<job_id>\d+)/$',
'atlantaice.web.views.show_job'),
(r'^employmentopp/(?P<job_id>\d+)/apply/$',
'atlantaice.web.views.job_apply'),
(r'^employmentopp/confirm/$',
'atlantaice.web.views.employment_confirm'),
(r'^eventrentals/$', 'atlantaice.web.views.event_rentals'),
(r'^eventrentals/popup/(?P<item>[0-9a-z\-]+)/$',
'atlantaice.web.views.show_popup'),
(r'^faqs/$', 'atlantaice.web.views.faq'),
(r'^iceestimator/$', 'atlantaice.web.views.ice_estimator'),
(r'^icemachines/$', 'atlantaice.web.views.ice_machines'),
(r'^pastevents/$', 'atlantaice.web.views.past_events'),
(r'^popup_blockice/$', 'atlantaice.web.views.popup_blockice'),
(r'^popup_dryice/$', 'atlantaice.web.views.popup_dryice'),
(r'^products/$', 'atlantaice.web.views.products'),
(r'^servicearea/$', 'atlantaice.web.views.service_area'),
(r'^services/$', 'atlantaice.web.views.services'),
(r'^testimonials/$', 'atlantaice.web.views.testimonials'),
(r'^weeklyroute/$', 'atlantaice.web.views.weekly_route'),
(r'^weeklyroute/confirm/$',
'atlantaice.web.views.weekly_route_confirm'),
(r'^admin/', include('django.contrib.admin.urls')),
On Jun 21, 7:12 pm, Graham Dumpleton <Graham.Dumple...@gmail.com>
wrote:
You must be using an older version of mod_python then. With older
versions of mod_python you would need to get access to mod_python
request object through the Django request object somehow and output
'req.interpreter'. Ie., access 'interpreter' attribute of mod_python
request object.
Nicest way of making this available which automatically shows in error
pages would be for the Django mod_python adapter to push the value
into the request environment.
> atlantaice.urls doesn't reference AGDWeb in any way.
:-(
I don't understand then how the two supposedly separate applications
are mixing data then. You most definitely have restarted Apache and
checked again after a restart?
Can you verify that you don't have any of the following directives
anywhere in your Apache configuration files:
PythonInterpreter
PythonInterpPerDirective
PythonInterpPerDirectory
Graham
On Jun 21, 9:34 pm, Graham Dumpleton <Graham.Dumple...@gmail.com>
On Jun 21, 11:29 pm, "rokclim...@gmail.com" <rokclim...@gmail.com>
wrote:
I'm running out of ideas. What it comes down to is that, according to
your traceback, for some reason under atlantaice the:
/djangosites/AGD/AGDWeb/views.py
module is being imported by the URL resolver in:
django/core/urlresolvers.py
when presumably you are expecting it to be the corresponding views
module for atlantaice.
To be honest I haven't ever done anything with Django past the hello
world examples, so I am presuming that the urls.py file is the only
place the resolver gets things from. Thus can't see why it would pick
up the wrong one if the two applications are indeed in their own
VirtualHost and thus their own Python sub interpreter.
The only way I know where a module could be shared between sub
interpreters under mod_python is where it is a C extension module as
Python only loads them once for all sub interpreters. For that reason
one can't use different versions of a C extension module in two
applications running in different sub interpreters. Anyway, that can't
be happening here urls.py is only a Python code module and not a C
extension module, plus that module when identified is prefixed by the
site name.
Thus we come back simply to verifying whether the two sites are
running in two different sub interpreters. Beyond that the only other
thing I can think of is PYTHONPATH is set in the environment of the
user that Apache is run as and that is causing a problem. Even that I
would be dubious of as your prefix the site directory to PythonPath so
it should be at the front.
BTW, I don't recollect you saying which version of mod_python you are
using. If you aren't using mod_python 3.3.1 I would strongly recommend
upgrading and trying that version instead. The only other suggestion
is you try mod_wsgi instead and use the daemon mode of mod_wsgi to
setup each site so they run in their own processes and so you don't
have multiple sub interpreters in the one process. That way there can
be no way they somehow could be interfering with each other. I can
help with that if you want to try that.
At the end of the day I am sure this will be something obvious and
I'll make a fool of myself for not seeing it earlier. ;-)
Graham
> On Jun 21, 9:34 pm, Graham Dumpleton <Graham.Dumple...@gmail.com>
> wrote:
>
> > On Jun 22, 10:14 am, "rokclim...@gmail.com" <rokclim...@gmail.com>
> > wrote:
>
> > > Interestingly, I am getting some strange errors when trying to output
> > > the interpreter ID to my error log. Attempting to do so generates an
> > > error in my logs:
>
> > > [Thu Jun 21 20:00:23 2007] [error] [client 209.155.235.13]
> > > PythonHandler django.core.handlers.modpython: File "/djangosites/
> > > atlantaice/settings.py", line 3, in ?\n
> > > apache.log_error("INTERPRETER %s" % apache.interpreter)
> > > [Thu Jun 21 20:00:23 2007] [error] [client 209.155.235.13]
> > > PythonHandler django.core.handlers.modpython: AttributeError: 'module'
> > > object has no attribute 'interpreter'
>
> > You must be using an older version ofmod_pythonthen. With older
> > versions ofmod_pythonyou would need to get access tomod_python
> > request object through the Django request object somehow and output
> > 'req.interpreter'. Ie., access 'interpreter' attribute ofmod_python
> > request object.
>
> > Nicest way of making this available which automatically shows in error
> > pages would be for the Djangomod_pythonadapter to push the value
> > > > when usingmod_python. I guess another suggestion I should create a
Graham, thank you for frequently answering questions that fall in the
gap between Django and mod_python, especially given your more recent
work on mod_wsgi.
No problem. Invariably people using Django or even other packages such
as TurboGears or Pylons never actually come over to the mod_python
list when they have problems, so me coming here is the only way I can
find out and understand what issues people are having which may relate
to mod_python. My ulterior motive of course is to make sure I know
what the problems are with mod_python so I can do it right in
mod_wsgi. Also, hopefully answering questions will give me some
credibility when it comes to trying to convince people that mod_wsgi
is a good idea and that the code that is already available and ready
to release is stable like I claim it is. :-)
Graham
On Jun 22, 5:43 am, Graham Dumpleton <Graham.Dumple...@gmail.com>
wrote:
Instructions linked off http://www.modwsgi.org (maps to Google code
site):
http://code.google.com/p/modwsgi/wiki/InstallationInstructions
Extra Django stuff in:
http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
Daemon process (fastcgi like) feature not really covered much in
documentation yet but given how you are having issues with two
applications intermingling data, may be better to be using daemon
process feature so that they are forced into separate processes. Thus
no risk of there being some back door method of data leaking between
sub interpreters.
The daemon process feature is controlled through additional
WSGIDaemonProcess/WSGIProcessGroup directives. Details for these in:
http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives
Hop on other to the mod_wgsi Google group if you start playing and
need some help which appears to be mod_wsgi specific.
Graham