On Nov 25, 4:52 pm, Graham Dumpleton <graham.dumple...@gmail.com> wrote: > On Nov 25, 3:23 pm, Crispin Wellington > > <cwelling...@ccg.murdoch.edu.au> wrote: > > Have a read of the mod_wsgi documentation, particularly the > > page:http://code.google.com/p/modwsgi/wiki/ApplicationIssues > > > Because Django uses environment variables to access the settings file, > > all kinds of strife can occur when running Django on top of mod_wsgi. > > Essentially Django and mod_wsgi don't play nicely when mod_wsgi is in > > its default configuration. You get applications swapping environments > > and all kinds of inexplicable bizarre errors occuring. > > Your imagination is running amuck, no such thing happens. You can > quite happily run multiple Django instances in embedded mode, they > just need to be separated into distinct Python sub interpreters, which > is the default behaviour of mod_wsgi. So, unless you have played with > WSGIApplicationGroup to override the default, there should be an > issue.
That of course should have read: """So, unless you have played with WSGIApplicationGroup to override the default, there should NOT be an issue.""" I have it when I leave out 'not' like that. :-) Graham > FWIW, it is mod_python that doesn't separate them properly if you have > multiple Django instances in one VirtualHost. This is because > mod_python only gives by default a sub interpreter to each VirtualHost > ServerName. So, sure you aren't confused. > > > As well as the environment problem, there is a particular insidious > > issue with time zone settings using Django under mod_wsgi that affects > > cookie expiry and thus django auth and login. > > That is only an issue where you have distinct applications, be they > Django or PHP, with different requirements for setting TZ. Not an > issue if all use the same. > > > The best approach is to run mod_wsgi in daemon mode, and allocate a > > specific process and thread pool to each django application. > > Even though embedded mode will work and for very high performance > sites, so long as Apache configured properly, is better, for most > mortals daemon mode is safer. > > Graham > > > > > This way > > you wont have python sub interpreters swapping applications they serve > > and getting confused. > > > Hope this helps. > > > Regards > > > Crispin Wellington > > > On Tue, 2009-11-24 at 19:12 -0800, Tom wrote: > > > Sorry, I should have mentioned that this has only come up after > > > deploying the project to a production server using mod_wsgi. It works > > > absolutely fine under development. > > > > Tom > > > > On Nov 25, 2:24 am, Tim Valenta <tonightslasts...@gmail.com> wrote: > > > > Are you using the development server? There's definitely caching > > > > funny-business in a production web server, but that should affect you > > > > if you're using "manage.py runserver" > > > > > Does stopping and starting the development server change anything? > > > > > Tim > > > > > On Nov 24, 6:54 pm, Tom <t.scr...@gmail.com> wrote: > > > > > > Hi all, > > > > > > I am experiencing TemplateDoesNotExist errors. Initially I thought I > > > > > had my TEMPLATE_DIRS variable set incorrectly, but much > > > > > experimentation yielded nothing. I then noticed that on the browser > > > > > TemplateDoesNotExist error pages the TEMPLATE_DIRS setting reads as an > > > > > empty tuple (). I then tried changing several other settings in > > > > > settings.py including database name and engine, and adding and > > > > > removing installed apps. None of these changes are showing up in the > > > > > settings listed on error pages. > > > > > > It seems like the settings file has been cached somewhere because > > > > > nothing I do to my settings.py file is making any difference. I have > > > > > even tried deleting the file altogether and still nothing changes. I > > > > > have also tried recreating my project from scratch, but still no joy. > > > > > > This is really weird; does anybody have any ideas what is going on? > > > > > > Thanks in advance, > > > > > > Tom > > > > -- > > > > You received this message because you are subscribed to the Google Groups > > > "Django users" group. > > > To post to this group, send email to django-us...@googlegroups.com. > > > To unsubscribe from this group, send email to > > > django-users+unsubscr...@googlegroups.com. > > > For more options, visit this group > > > athttp://groups.google.com/group/django-users?hl=en.- Hide quoted text - > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
