Temporarily replace the WSGI scripts with the one in: http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Sub_Interpreter_Being_Used
and verify which application group (interpreter) each is run in. Double check you do not have any of WSGI directives in the Apache configuration. Also, do you have ServerName set in that VirtualHost? Graham On 20/06/2013, at 1:03 PM, Matthew Reinbold <[email protected]> wrote: > Right. I read your post and my WSGI file should be set up in the correct way > (if I understand the post correctly). > > The WSGI for production: > import os > import sys > > path = 'E:\\sites\\mysite' > if path not in sys.path: > sys.path.append(path) > > os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings' #note, the way the > django project was created, the settings for this site at > E:\\sites\mysite\mysite\settings.py > > import django.core.handlers.wsgi > application = django.core.handlers.wsgi.WSGIHandler() > > And the WSGI for demo is: > import os > import sys > > path = 'E:\\sites\\mysite.staging' > if path not in sys.path: > sys.path.append(path) > > os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings' #note, the way the > django project was created, the settings is at > E:\\sites\mysite.staging\mysite\settings.py > > import django.core.handlers.wsgi > application = django.core.handlers.wsgi.WSGIHandler() > > Clear as mud? > > On Wednesday, June 19, 2013 5:39:00 PM UTC-6, Graham Dumpleton wrote: > Post your WSGI script file for both sites. > > Did you pay attention to the post at: > > http://blog.dscpl.com.au/2012/10/requests-running-in-wrong-django.html > > which I gave in the SO post and which notes the importance of setting > DJANGO_SETTINGS_MODULE in a certain way? > > The default that Django creates is wrong these days. > > Graham > > On 20/06/2013, at 7:50 AM, Matthew Reinbold <[email protected]> wrote: > >> This is a continuation of a post I had over on StackOverflow. Since Graham >> seemed to have all the answers over there, I thought I'd just come to the >> source. ;) >> >> I managed to get my Apache 2.4 configuration running successfully on a 64x >> Windows server. I now am able to use two different WSGI alias values to >> switch between two different django code directories; a live branch and a >> demo (or staging) branch. I configured Apache this way so that the purchased >> and installed SSL certificate would work for either URL as the hostnames >> remain the same. The relevant part of the Apache conf file is below: >> >> <VirtualHost _default_:443> >> # config stuff for the certificate >> >> Alias /static "E:/sites/static" >> ErrorLog "logs/api.mysite.log" >> CustomLog "logs/api.mysite.log" combined >> >> WSGIScriptAlias /demo "E:/sites/mysite.staging/django.wsgi" >> WSGIScriptAlias /v1 "E:/sites/mysite/django.wsgi" >> WSGIPassAuthorization On >> >> </VirtualHost> >> >> That works: I can hit links at both https://mysite.com/v1/blahblahblah/ and >> https://mysite.com/demo/blahblahblah. >> >> However (you might see where I'm going with this) those site aren't >> distinct. If I put some additional 'Hello World' logging code in the >> mysite.staging directory and restart Apache, I never see the 'Hello World' >> appear in the log file. >> >> My guess is that the production version of associated code is getting called >> first immediately after restart. That loads the modules of my django code >> for the production instance. Then when I hit the demo version, because its >> all shared memory space, the module needed to be called is seen to be in >> memory and that is being used, even though I want the demo version of the >> code, not production. >> >> Questions: >> Is this memory race condition, as I've described, most likely what is >> happening? >> I can't isolate the sites with a Daemon process as I've seen described >> elsewhere as I'm on a windows server. If the race condition is happening, is >> there some other variable or setting within Django to ensure that modules >> live within their own "application space"? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/modwsgi. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> > > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/groups/opt_out.
