search

jvandal / modwsgi

Automatically exported from code.google.com/p/modwsgi
0 stars 0 forks source link

global variables reset on every request, what I am doing wrong ? #157

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Environment:Using webfaction hosting, with RedHat, Apache, and modwsgi2.5, 
with python 2.5.4, packages : WebOb and Jinja2. DB : PostGres 8.3
What steps will reproduce the problem?
1.App. have global variables like db connection and jinja2 environment, 
but on every request start from beginning, what changes should I make.

Thanks in advance
Joaquin Berenguer
chimobb@hotmail.com

Original issue reported on code.google.com by chimo.be...@gmail.com on 30 Sep 2009 at 8:29

GoogleCodeExporter commented 8 years ago 
Depending on how you configure Apache/mod_wsgi, you may be using a multi 
process configuration. Thus, 
subsequent requests don't necessarily go to the same process. As a result, 
initialisation would need to be done in each 
process. This may be confusing you. Use os.getpid() to get process ID and log 
it to sys.stderr so you can see whether 
same process or not.

Other possibilities are that your global variable initialisation isn't thread 
safe and under load initial threads may be 
stomping on each other. Alternatively, you could have configured mod_wsgi 
wrongly by trying to use 
WSGIScriptAliasMatch when you shouldn't and stuffed up definition such that 
every URL gets handled in separate sub 
interpreter. If you had done the latter, likely though you would have blown out 
your memory usage and so would have 
noticed.

Also read:

  http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading

Original comment by Graham.Dumpleton@gmail.com on 30 Sep 2009 at 11:18

GoogleCodeExporter commented 8 years ago 
Apache configured by hosting supplier, that give me possibility to add WSGI 
application.
mod_wsgi is in embedded mode, and only using WSGIScripAlias.
As you said seems  that global variables are not thread safe, I am looking for 
what 
kind of issues, using getpid() to discover problems. 
Thanks for the link.

Regards
chimobb@hotmail.com

Original comment by chimo.be...@gmail.com on 1 Oct 2009 at 3:50

GoogleCodeExporter commented 8 years ago 
No, if using embedded mode it is multiprocess. Thread safety is not going to be 
the issue. So do the getpid() 
checks.

Also use first code snippet in:

  http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Tracking_Request_and_Response

to wrap your WSGI application entry point.

Then look at error logs and see what:

  wsgi.multiprocess
  wsgi.multithread

are set to.

If wsgi.multiprocess is True, then will be as I said.

BTW, if you are using a shared Apache instance with other users, your hosting 
supplier should never have 
used embedded mode. They should use daemon mode and delegate your specific WSGI 
application to daemon 
process group where you are the owner of the process. Embedded mode is not 
secure in a shared hosting 
environment. Not for you and not for the hosting supplier.

Original comment by Graham.Dumpleton@gmail.com on 1 Oct 2009 at 10:48

GoogleCodeExporter commented 8 years ago 
Graham,

Thanks, clear, using my local Apache works fine because I am using 1 process 
several 
threads, but at Webfaction, several processes are started loosing global 
variables 
values, I will need to build some shared mechanism, do you recommend some 
solution 
for this ?

Chimo

Original comment by chimo.be...@gmail.com on 3 Oct 2009 at 10:19

GoogleCodeExporter commented 8 years ago 
Use mod_wsgi daemon mode and have your WSGI application run in single process 
with many threads. See 
WSGIDaemonProcess/WSGIProcessGroup directives and examples in:

  http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide

Original comment by Graham.Dumpleton@gmail.com on 3 Oct 2009 at 11:37

GoogleCodeExporter commented 8 years ago 
Graham,

I have configured mod_wsgi as you said, what could be the maximum number of 
threads ?
More than 256 ?

Original comment by chimo.be...@gmail.com on 7 Oct 2009 at 10:24

GoogleCodeExporter commented 8 years ago 
For embedded mode, that is dictated by your Apache configuration. For prefork 
MPM it is single threaded. For 
worker MPM, it is dictated by ThreadsPerChild directive in Apache MPM settings. 
The default number for 
worker MPM in files shipped by Apache is 25 threads per child process.

For daemon mode it defaults to 15 threads per daemon process. This is 
overridden by 'threads' argument to 
WSGIDaemonProcess directive.

So, number of threads is really up to what you set it to, with fallback to 
those defaults if defaults haven't been 
changed.

Original comment by Graham.Dumpleton@gmail.com on 7 Oct 2009 at 10:28

GoogleCodeExporter commented 8 years ago 
Closing as don't see that any action needs to be taken as was due to behaviour 
implicit in configuration being 
used.

Original comment by Graham.Dumpleton@gmail.com on 18 Nov 2009 at 6:41