On 24 January 2011 23:35, JE <[email protected]> wrote:
> Hi !
>
> I have got a quick question. We have started running two different
> virtual hosts on the same server, and thought that we can have them
> both run in the same WSGIDaemonProcess group. It seems that it doesn't
> work as expected - because there are some mixup happening as requests
> are processed. We are trying to figure out if the cause is our
> mod_wsgi config or may be our python modules itself.
>
> While reading through the documentation of mod_wsgi we found that the
> description of WSGIDaemonProcess seems to have contradicting
> statements:
> [...]
> Note that the name of the daemon process group must be unique for the
> whole server. **That is, it is not possible to use the same daemon
> process group name in different virtual hosts.**
What this means is that you cannot have:
<VirtualHost *:80>
...
WSGIDaemonProcess myname ...
</VirtualHost>
<VirtualHost *:80>
...
WSGIDaemonProcess myname ...
</VirtualHost>
This is because the group name argument, ie., 'myname', is not unique
across the whole server.
> [...]
> If **the WSGIDaemonProcess directive is specified outside of all
> virtual host containers**, any WSGI application can be delegated to be
> run within that daemon process group.
> [...]
What this means is that you can have:
WSGIDaemonProcess myname ...
<VirtualHost *:80>
...
WSGIProcessGroup myname ...
</VirtualHost>
<VirtualHost *:80>
...
WSGIProcessGroup myname ...
</VirtualHost>
> So my question is can we have a WSGIDaemonProcess directive with the
> same name for different virtual hosts, by putting it into the server
> config?
As above, you cannot have two instances of WSGIDaemonProcess directive
with the same name. You can however have one WSGIDaemonProcess
directive using a specific name which is then delegated to from
multiple places using WSGIProcessGroup or other means of delegation.
> Additional info: the applicationgroup is %{GLOBAL}% and we have
> multiple processes.
This would be dangerous to do where the WSGI applications being run do
not support being able to run multiple instances within the same
Python interpreter. Django and web2py are both examples of Python web
frameworks where you cannot run more than one instance in the same
interpreter.
A few other notes about WSGIDaemonProcess/WSGIProcessGroup.
First off, WSGIProcessGroup inside of a VirtualHost can refer to named
daemon process group set up with matching name where:
1. WSGIDaemonProcess is specified outside of all VirtualHost definitions.
2, WSGIDaemonProcess is inside of the same VirtualHost and preceding
the WSGIProcessGroup directive which is referring to it.
3. WSGIDaemonProcess is inside of another VirtualHost which has the
same ServerName directive value, but where the listener port for the
virtual host is different. This other VirtualHost containing the
WSGIDaemonProcess directive must have been parsed by Apache before
that which has the WSGIProcessGroup directive which refers to it.
Also, a couple of notes about WSGIApplicationGroup.
By default this has a value of %{RESOURCE}, which constructs a name
for the sub interpreter to use from the name of the host for the
virtual host or whole server (as appropriate), the listener port for
that specific virtual host or whole server (as appropriate) and the
mount point of the WSGI application.
The only exception for this is that for port 80/443, the port is
dropped from the name of the sub interpreter used. This is to ensure
that when 80/443 are both delegated to same daemon process group, that
requests go to single instance in same sub interpreter. Ie., where
using:
WSGIDaemonProcess myname ...
<VirtualHost *:80>
ServerName example.com
...
WSGIProcessGroup myname ...
</VirtualHost>
<VirtualHost *:443>
ServerName example.com
...
WSGIProcessGroup myname ...
</VirtualHost>
or:
<VirtualHost *:80>
ServerName example.com
...
WSGIDaemonProcess myname ...
WSGIProcessGroup myname ...
</VirtualHost>
<VirtualHost *:443>
ServerName example.com
...
WSGIProcessGroup myname ...
</VirtualHost>
Note how in second the WSGIDaemonProcess is inside of VirtualHost, but
since ServerName is same then can be referred to from port 443 variant
of virtual host for same ServerName.
Also be aware that for this 80/443 case, it is assumed that the
WSGIScriptAlias refers to same WSGI script file and application setup.
Ie, the only difference is that some requests will be via SSL
connection from client.
As to your problem of mixed up requests, this can also occur for a
number of reasons besides a web framework that can't have multiple
instances in same interpreter.
One cause is where running each in separate sub interpreters of same
process. Some packages/modules for Python which have a C extension
module component are designed properly to work in sub interpreters, or
multiple sub interpreters at the same time. As a consequence they can
leak data between sub interpreters and cause problems.
Another potential problem is where within different sub interpreters
you are using different versions of the same package which a C
extension module component. Python should allow you to load both C
extension modules as it distinguishes based on file system location.
However, if the extension modules doesn't hide all its data as statics
and symbols have global linkage, then you can have the different
extension module versions sharing data which again can cause problems.
Finally, you can have general problems with leakage of environment
variables between sub interpreters, plus issues with fact that some
settings such as timezone and locale/language are process wide and not
sub interpreter specific. Thus setting in one application will affect
the other. You can also have issues with current working directory
being changed and thus why you should never rely on what the current
working directory is. The web2py framework changes the current working
directory and thus it may be dangerous to run multiple instances in
different sub interpreters of same process. For more details on some
of these latter issues see:
http://code.google.com/p/modwsgi/wiki/ApplicationIssues
Overall, the safest thing to do is to have each distinct web
application instance delegated to its own daemon process group, with
it being forced to run in %{GLOBAL} application group of that daemon
process group. The %{GLOBAL} here means force it to run in the main
(first created) Python interpreter within the process. This is
equivalent to the interpreter environment which is used by command
line Python and so all C extension modules should work in that.
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.
