On 4 July 2012 09:07, Benjamin Bach <[email protected]> wrote: > > > On Wednesday, July 4, 2012 12:05:36 AM UTC+2, Graham Dumpleton wrote: >> >> >> >> If the auto generated wsgi.py is using setdefault they have broken it very >> badly. When running in a multiple sub interpreter process, the first wsgi.py >> in any sub interpreter will win for the whole process. This is because >> setting os.environ, pushes values back out to process scope and when next >> sub interpreter is created it will pick up the value of the environment >> variable leaked from the other sub interpreter. >> >> I will have to look at original Django and if this is what they are doing, >> then yell a people about it. >> >> To fix, don't use setdefault. Just use '=' to set value in os.environ. >> >> Graham > > > Thanks, I will try with this solution ASAP and I think indeed judging from > the symptoms that this was the sole cause. > > The Django people have written their documentation about WSGI here: > > https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/ > > I think it should clearly mention that this can have harmful effects, > unfortunately it doesn't, and there is a wontfix on the issue here: > https://code.djangoproject.com/ticket/18518 > > I'll open up a ticket for the documentation instead.
Thanks for finding that existing ticket. I have added a comment but my state of mind right now is such that not holding much hope that anything will be done. If they want the existing behaviour for other systems they could provide a check for when mod_wsgi and not do that, but highly unlikely that they would add server specific checks. Graham -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
