> On 3 Mar 2021, at 12:39 pm, Ezra Peisach <[email protected]> wrote:
>
>
> Ok, this will be complicated.
> Recently moving to Python3,
> Running mod_wsgi from apache,
>
> We needed to add:
>
> WSGIApplicationGroup %{GLOBAL}
>
> due to third party code (numpy, lxml). This means that requests are served by
> primary python process
No, that isn't what it means. Setting the application group forces which sub
interpreter context within each process is used. In this case it sets it to the
main or first interpreter context, which behaves like command line Python.
There will still be a copy of this application (interpreter context) in all 10
of the processes in the daemon process group.
> WSGIDaemonProcess wsgi_app_ssl processes=10 threads=1
> python-path="/path_to_venv..."
>
> WSGIProcessGroup wsgi_app_ssl
>
> We then have some scripts:
>
> WSGIScriptAlias /service/review_v2
> /path/doServiceRequest_review.wsgi
>
> WSGIScriptAlias /service/status_update_tasks_v2
> /path/doServiceRequest_ctl_v2.wsgi
>
> .....
>
>
This is where may now have a problem as setting the application group globally
means both those WSGI applications now run in the same sub interpreter context
of each process. If those WSGI applications are not compatible when run
together, eg., try and both use same global data object of imported module for
different things, then you can get problems.
> Application handling is a standard
>
>
>
> from webob import Request, Response
>
> def __call__(self, environment, responseApplication):
>
> myRequest = Request(environment)
>
> .....
>
> After a single request is processed with a file that is being uploaded in a
> FieldStorage
>
> The issue is that after the request, the file descriptor is still open, but
> deleted (using lsof).
>
> This file appears to be open in every process.of httpd. (same filename).
>
>
That would only be the case if there had been multiple requests against the
WSGI application.
As mentioned above, there is still a copy of the WSGI application in each
process, and thus as each process handles a request, then that process would
also end up opening the file.
> a) Is the apache configuration correct in this case?
>
>
It is okay, but with concern over whether your multiple WSGI applications can
now run together in the same sub interpreter context.
If both WSGI applications use numpy, you would have to use multiple daemon
process groups and keep them separate.
# Add this outside of VirtualHost to ensure only daemon mode used.
WSGIRestrictEmbedded On
# Two daemon process group.
WSGIDaemonProcess wsgi_app_ssl_1 processes=5 threads=1
python-path="/path_to_venv..."
WSGIDaemonProcess wsgi_app_ssl_2 processes=5 threads=1
python-path="/path_to_venv..."
# Force first into one daemon process group.
WSGIScriptAlias /service/review_v2 /path/doServiceRequest_review.wsgi
process-group=wsgi_app_ssl_1 application-group=%{GLOBAL}
# And second into other daemon process group.
WSGIScriptAlias /service/status_update_tasks_v2
/path/doServiceRequest_ctl_v2.wsgi process-group=wsgi_app_ssl_2
application-group=%{GLOBAL}
If one doesn't use numpy, then you can restrict which one has to run in the
main interpreter context.
# Add this outside of VirtualHost to ensure only daemon mode used.
WSGIRestrictEmbedded On
# Single daemon process group.
WSGIDaemonProcess wsgi_app_ssl processes=10 threads=1
python-path="/path_to_venv..."
# Force one using numpy into main interpreter context.
WSGIScriptAlias /service/review_v2 /path/doServiceRequest_review.wsgi
process-group=wsgi_app_ssl application-group=%{GLOBAL}
# For second application group not specified, meaning it will run in named
sub interpreter where name based on host and URL mount point.
WSGIScriptAlias /service/status_update_tasks_v2
/path/doServiceRequest_ctl_v2.wsgi process-group=wsgi_app_ssl
Note I am using options to WSGIScriptAlias to set process group and application
group instead of the separate directives.
> b) Am I missing something here - i.e. is WebOB at fault here?
>
> WebOB uses cgi - which has a cleanup __del__ which is supposed to close the
> file - but.I have not debugged down that far....
>
>
Relying on __del__ to cleanup file descriptors can be bad because if something
holds the object in memory, it may only be cleaned up later when garbage
collector kicks in.
Anyway, hope that helps explain things.
Graham
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/modwsgi/9D3B14DB-861B-4B3E-AD3F-91E855A9F8D6%40gmail.com.
