More mod_wsgi weirdness: process restarts on redirect

[Ron Garret]

In article 
<63cf7deb-f15c-4259-aa24-1b8da846876d at r41g2000prr.googlegroups.com>,
 Graham Dumpleton <Graham.Dumpleton at gmail.com> wrote:

> On Jan 30, 11:01 am, Ron Garret <rNOSPA... at flownet.com> wrote:
> > In article <mailman.8321.1233272610.3487.python-l... at python.org>,
> >  Joshua Kugler <jos... at 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