mod_wsgi daemon mode - WSGIDaemonProcess per virtual host configuration?

Solution 1:

Quoting the documentation at:

http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess

behaviour is:

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. If the WSGIDaemonProcess directive is specified within a virtual host container, only WSGI applications associated with virtual hosts with the same server name as that virtual host can be delegated to that set of daemon processes.

So, you can reach across to daemon process definition in prior virtual host so long as same server name.

You also need to be aware of what is said in:

http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIApplicationGroup

whereby for default for WSGIApplicationGroup (ie., if not specified) is:

%{RESOURCE}

The application group name will be set to the server hostname and port as for the %{SERVER} variable, to which the value of WSGI environment variable SCRIPT_NAME is appended separated by the file separator character.

For example, if the virtual host www.example.com was handling requests on port 8080 and the URL-path which mapped to the WSGI application was http://www.example.com/wsgi-scripts/foo, then the application group name would be set to www.example.com:8080|/wsgi-scripts/foo.

The effect of using the %{RESOURCE} variable expansion is for each application on any server to be isolated from all others by being mapped to its own Python sub interpreter.

So, normally if you had separate WSGIScriptAlias for same mount point in the two virtual hosts for different ports, the two application instances would still be separated by running in different sub interpreters.

There is an exception to this rule though for the port 80/443 case whereby the port isn't actually included in the application group name. Thus in that case, applications mounted at same mount point would run in same sub interpreter.

This exception probably isn't explained as clearly as it could, but is covered by the definition:

%{SERVER}

The application group name will be set to the server hostname. If the request arrived over a non standard HTTP/HTTPS port, the port number will be added as a suffix to the group name separated by a colon.

For example, if the virtual host www.example.com is handling requests on the standard HTTP port (80) and HTTPS port (443), a request arriving on either port would see the application group name being set to www.example.com. If instead the virtual host was handling requests on port 8080, then the application group name would be set to www.example.com:8080.

that expansion of that being used as part of the default expansion above.