[modwsgi] Re: mod_wsgi (3.4-14) / Apache 2.4.12 / cx_oracle 5.2 / Oracle 12 / Red Hat (6.7) / Django 1.8.2 hanging under load

['Lukasz Szajkowski' via modwsgi]

Deadlock shows that application hangs trying to load modules (from django 
or built-in etc.). Normally it should be done only once at start-up, but in 
our case it's after many requests (*Why)*. So possible explanations:
   * python process/interpreter is killed/restarted from outside (e.g. by 
logrotate) and starts to import modules again

   * internal mod_wsgi monitor thread kills and restarts python (
https://github.com/GrahamDumpleton/mod_wsgi/blob/3.4/mod_wsgi.c#L11157)

   * lazy load of application leads to late imports - added options to 
mod_wsgi to force early application load (default it lazy load)

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To post to this group, send email to modwsgi@googlegroups.com.
Visit this group at http://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.

Re: [modwsgi] Re: mod_wsgi (3.4-14) / Apache 2.4.12 / cx_oracle 5.2 / Oracle 12 / Red Hat (6.7) / Django 1.8.2 hanging under load

[Graham Dumpleton]

> On 6 Oct 2015, at 6:32 pm, 'Lukasz Szajkowski' via modwsgi 
>  wrote:
> 
> Deadlock shows that application hangs trying to load modules (from django or 
> built-in etc.). Normally it should be done only once at start-up, but in our 
> case it's after many requests (Why). So possible explanations:
>* python process/interpreter is killed/restarted from outside (e.g. by 
> logrotate) and starts to import modules again
> 
>* internal mod_wsgi monitor thread kills and restarts python 
> (https://github.com/GrahamDumpleton/mod_wsgi/blob/3.4/mod_wsgi.c#L11157 
> )
> 

Both of the above would result in a completely new process being created. There 
shouldn’t be any case where Python is reinitialised in the same process.

For a process restart wouldn’t be so concerned.
>* lazy load of application leads to late imports - added options to 
> mod_wsgi to force early application load (default it lazy load)
> 

This could definitely be an issue, especially if imports are done from within 
functions rather than global scope.

Lets try another things just to make sure that everything Python is at least 
happening in daemon processes as it should.

For this, ensure that you are setting:

WSGIRestrictedEmbedded On

This will ensure that Python isn’t being initialised inside any Apache child 
worker processes. If for some reason configuration was getting applied wrongly 
and request ran in child worker process rather than daemon processes, this 
would come up as an error with that setting.

The other thing one can do to be absolutely certain things running in right sub 
interpreter context, is that instead of doing:

WSGIDaemonProcess xxx
WSGIProcessGroup xxx
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias / /some/path/app.wsgi

use:

WSGIDaemonProcess xxx
WSGIScriptAlias / /some/path/app.wsgi process-group=xxx 
application-group=%{GLOBAL}

This will ensure everything runs in main interpreter context of daemon process 
‘xxx’ and not subject to Apache context matching rules to ensure that 
WSGIProcessGroup/WSGIApplicationGroup are applied correctly.

Use of the process-group and application-group options together on 
WSGIScriptAlias will also have the side effect of preloading the WSGI script 
file on process start rather than lazily on first request.

This only applies to the WSGI script file itself and direct module imports. 
Django itself will lazily load view handlers for URLs still and so code for 
those can still be lazily loaded.

The only away around that is as a side effect of loading WSGI script, use 
WebTest or something to fake requests into the Django application instance for 
certain key URLs to force it to load code then.

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 modwsgi+unsubscr...@googlegroups.com.
To post to this group, send email to modwsgi@googlegroups.com.
Visit this group at http://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.

[modwsgi] Compiled version different than runtime when using BeautifulSoup

[Ericson Willians]

I've posted this problem on Stack Overflow:

http://stackoverflow.com/questions/32976336/mod-wsgi-compiled-version-different-than-runtime-when-using-beautifulsoup

mod_wsgi works perfectly on Apache 2.4.16 with Python 3.4, except when I 
use BeautifulSoup. For some reason, the app does not load, and I get SSL 
warnings, as well as version mismatch warnings on logs/error.log. Anyone 
has any idea?? 

Thank you very very much!

-- 
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 modwsgi+unsubscr...@googlegroups.com.
To post to this group, send email to modwsgi@googlegroups.com.
Visit this group at http://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.