Both are valid configurations and can work, but achieve different results. What you don't show is how you are mounting the WSGI applications. Are you using WSGIScriptAlias or are you using AddHandler/SetHandler? Also what web framework are you running?
Without that information and also a better description of the actual errors/problems you were getting, is hard to suggest why the first configuration would give you a problem. For all I know when you are saying 'with code being imported/run from all over the place, seemingly at random' you might be talking about code being loaded at times you don't expect, albeit still the right code. That can well be the case with embedded mode because it is a multiprocess configuration on Linux systems. Graham On 11/10/2013, at 9:47 PM, Kaleissin - <[email protected]> wrote: > I took over development of a site recently and was having trouble with code > being imported/run from all over the place, seemingly at random. On the > dev-server, multiple copies of the same site was running, some with > WSGIDaemonProcess (mod_wsgi 3.3), others embedded. Having them all use > WSGIDaemonProcess didn't solve the problem (and yes, there were > WSGIProcessGroup in the same file). > > Turns out: > > The staging copy runs two daemon-processes, one single-threaded (processes=1 > threads=1 set explicitly) and one not. One <Location> was set to use the > single threaded group, several, but not all, other locations were set to use > the multithreaded group. I moved the multithreaded WSGIProcessGroup to the > level of the virtual host, and kept the singlethreaded WSGIProcessGroup for > the one spot it was needed. No more clashes, code was fetched from the right > place. However... The <location> that needs to be single threaded isn't, > judging by the errors I get. > > If I read > https://modwsgi.readthedocs.org/en/latest/configuration-directives/WSGIProcessGroup.html > correctly, a WSGIProcessGroup set inside a <location> overrides the > WSGIProcessGroup set outside. Is this correct, and if so, why isn't the one > location with an override actually overidden? > > Secondly, if: > > WSGIDaemonGroup foo > WSGIDaemonGroup bar > WSGIProcessGroup foo > > <location /xux> > WSGIProcessGroup bar > </location> > > <location /gurba> > .. > </location> > > <location /meepmeep> > # Non-python stuff > </location> > > properly separates the processes while: > > WSGIDaemonGroup foo > WSGIDaemonGroup bar > > <location /xux> > WSGIProcessGroup bar > </location> > > <location /gurba> > WSGIProcessGroup foo > </location> > > <location /meepmeep> > # Non-python stuff > </location> > > doesn't, shouldn't that be documented? > > Or am I barking up the wrong tree here? > > > K > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/groups/opt_out. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/groups/opt_out.
