On Jan 30, 11:01 am, Ron Garret <rnospa...@flownet.com> wrote: > In article <mailman.8321.1233272610.3487.python-l...@python.org>, > Joshua Kugler <jos...@joshuakugler.com> wrote: > > > Ron Garret wrote: > > > My question is: is this supposed to be happening? Or is this an > > > indication that something is wrong, and if so, what? > > > You are probably just hitting a different instance of Apache, thus the > > different process ID. > > Yep, that's what it turned out to be. I thought I had a > WSGIDaemonProcess processes=1 directive in my config, but I had it in > the wrong place (a different vhost) so it wasn't actually active. > http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading > But that leaves me wondering why the redirect would reliably trigger > switching processes. The reason I thought that I had the correct > configuration and only had one process is that when I reloaded the > non-redirected page I *always* got the same process ID. How > doesmod_wsgidecide which process (and which thread for that matter) to use?
Details on process/threading in mod_wsgi available at: http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading When using WSGIDaemonProcess directive, if you want a single process it is better to allow it to default to a single process and not have 'processes=1'. As soon as you say 'processes=1' it will trigger wsgi.multiprocess to be True rather than default of False. This may sound counter intuitive, but is a little back door to allow wsgi.multiprocess to be set to True somehow when distributing an application across a cluster of machines where it does need to be True even if each machine only has a single process for that application. Tthat wsgi.multiprocess is True will not usually matter unless you are trying to use debugging middleware that require that there only be a single process. As to why you were getting a different process, because you were actually running in embedded mode due to WSGIDaemonProcess/ WSGIProcessGroup being in wrong context, then what process was used was really up to Apache and how it works. Specifically it can have multiple processes that can listen on the HTTP port (80). Because only one should be listening at a time it uses a cross process mutex lock to mediate access. When a process handles a request, it gives up the lock. If using worker MPM then another thread in same process may get lock, or for either worker MPM or prefork MPM, then another process could get it. Which actually gets it is a bit indeterminate as simply depends on which process the operating system lets have the lock next. So, there is no strict rule one can say as to who would get it next. Graham Graham -- http://mail.python.org/mailman/listinfo/python-list