On Mon, Jul 20, 2009 at 1:20 AM, Graham
Dumpleton<[email protected]> wrote:
>
> 2009/7/20 Graham Dumpleton <[email protected]>:
>> 2009/7/20 Graham Dumpleton <[email protected]>:
>>> 2009/7/20 Malcolm <[email protected]>:
>>>>
>>>> Hello,
>>>>
>>>> I am using mod_wsgi 2.3 with Apache 2.2.11 on Ubuntu 9.04.
>>>>
>>>> I seem to be having problems where the code I put in on of my WSGI
>>>> application files, (django.wsgi) is affecting the (sub) interpreters
>>>> of other WSGI applications.
>>>>
>>>> Here is the relevant part of the django.wsgi file:
>>>> ----------
>>>> ...
>>>> import warnings
>>>> warnings.filterwarnings(action="ignore",
>>>> message="^the sets module is deprecated$",
>>>> category=DeprecationWarning,
>>>> module="MySQLdb", lineno=34)
>>>>
>>>> # Determine the absolute path of the Django project directory that
>>>> contains
>>>> # this
>>>> project.
>>>> ...
>>>>
>>>> # If the Django project directory is not in the Python path, add
>>>> it.
>>>> ...
>>>>
>>>> os.environ['DJANGO_SETTINGS_MODULE'] = DJANGO_PROJ + '.settings'
>>>>
>>>> import django.core.handlers.wsgi
>>>> application = django.core.handlers.wsgi.WSGIHandler()
>>>> ----------
>>>>
>>>> In the above WSGI application file, I suppress a warning emitted by a
>>>> particular module. I expected this warning to be suppressed only for
>>>> this one WSGI application, but this is not the case. Say I go to /
>>>> site1 where the WSGI application file suppresses the warning, then
>>>> sure enough, there will be no warning in the Apache error log.
>>>> However, if after visiting that WSGI application, I now go to /site2
>>>> (another WSGI application that doesn't have that warning suppressed),
>>>> the warning does not show up.
>>>>
>>>> Yet, if I restart Apache and visit /site2 first, the warning will
>>>> appear in the log.
>>>>
>>>> I am running mod_wsgi in daemon mode with multiple WSGI applications.
>>>> All the applications are running within the same process group;
>>>> however, I can change this if I need to. I am using the Apache prefork
>>>> MPM, and I have only one virtual host.
>>>>
>>>> I know this problem seems small and insignificant, since it is just
>>>> affecting spam output to the Apache error log. However, it signals a
>>>> larger problem for me: it means that my WSGI applications are somehow
>>>> sharing state, which I don't want.
>>>
>>> The separation between sub interpreters isn't always perfect. If a C
>>> extension module is used in implementing a Python module isn't
>>> implemented correctly so as to separate data for different sub
>>> interpreters properly, you can have issues.
>>>
>>> In this case though, we are talking about a core Python module and for
>>> it I suspect it is operating on the Python core and so all
>>> interpreters within the process and not just the one the module was
>>> used from are affected. A quick look at the code shows:
>>>
>>> try:
>>> from _warnings import (filters, default_action, once_registry,
>>> warn, warn_explicit)
>>> defaultaction = default_action
>>> onceregistry = once_registry
>>> _warnings_defaults = True
>>> except ImportError:
>>> filters = []
>>> defaultaction = "default"
>>> onceregistry = {}
>>>
>>> So, what it does is try and import 'filters' from C extension module
>>> _warnings. That value is a list and is actually a reference to a
>>> global static C variable. As such, the same list will be imported into
>>> all sub interpreters and changes made in one sub interpreter will
>>> change what happens in other sub interpreters.
>>>
>>> This sharing of data between sub interpreters is actually usually not
>>> a good thing to do and so am surprised to see this. I will have to do
>>> a bit more research on this and post to the Python list asking about
>>> why it is this way since it doesn't provide proper isolation for sub
>>> interpreters.
>>>
>>> BTW, in mod_wsgi 3.0, you can use the WSGIPythonWarnings directive to
>>> control warnings from configuration file.
>>>
>>> WSGIPythonWarnings ignore::DeprecationWarning::
>>>
>>> This is done when Python first initialised and affects all sub
>>> interpreters. But then, as you have demonstrated, there is no
>>> separation where control of warnings is concerned.
>>>
>>> Anyway, for proper separation, looks like you will need to delegate
>>> each WSGI application to a different daemon process group.
>>>
>>> Thanks for raising this issue as I didn't know about it.
>>
>> The other thing you may be able to do is:
>>
>> import warnings
>> warnings.filters = list(warnings.filters)
>> warnings.onceregistry = list(warnings.onceregistry)
>
> Whoops.
>
> warnings.onceregistry = dict(warnings.onceregistry)
Hi Graham,
Thanks for the quick reply.
I don't quite understand what the above three lines would do. Also,
since it could cause some unexpected behaviour, maybe it's better to
go with the a separate daemon process per application. But I'm not
quite sure how to do that. Here's my Apache configuration pertaining
to WSGI:
----------
WSGIDaemonProcess MainGroup
WSGIProcessGroup MainGroup
WSGIScriptalias /vc /usr/local/lib/django-projects/vc/apache/django.wsgi
<Directory /usr/local/lib/django-projects>
Order Deny,Allow
Allow from all
</Directory>
Alias /vc/media /usr/local/lib/django-projects/vc/media
# Personal Django workspaces. Basically, this allows users on the
# system to host multiple Django projects in ~/django-projects/, and
# access them via http://<domain>/~<username>/<project_name>.
WSGIScriptAliasMatch ^/~([^/]+)/([^/]+)
/home/$1/django-projects/$2/apache/django.wsgi
<DirectoryMatch ^/home/([^/]+)/django-projects/([^/]+)/media>
Order Deny,Allow
Allow from all
</DirectoryMatch>
AliasMatch ^/~([^/]+)/([^/]+)/media/(.*) /home/$1/django-projects/$2/media/$3
----------
All of the above is contained within one virtual host. So, if I
understand the WSGI directives correctly, currently, all WSGI
applications are running within the MainGroup process group. How can I
specify that each application, even within the "personal Django
workspaces", as I call them, should be in a unique process group? Is
this even possible?
-Malcolm
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
