In article <63cf7deb-f15c-4259-aa24-1b8da8468...@r41g2000prr.googlegroups.com>, Graham Dumpleton <graham.dumple...@gmail.com> wrote:
> 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 Thanks! rg
-- http://mail.python.org/mailman/listinfo/python-list
