On Jul 8, 11:32 pm, yannick <[email protected]> wrote:
> Finally found it. The WSGIProcessGroup qubicbackoffice directive
> should have been placed in the Directory block. Wonder why it's placed
> there by modwsgi_deploy seeing how it's apparently not processed when
> out of place!
> Anyways, thanks for your help, and I hope by posting this I can help
> someone someday...

You could always make it explicitly by saying:

  WSGIScriptAlias /test /usr/local/turbogears/qubic.backoffice/apache/
test.wsgi \
    process-group=qubicbackoffice application-group=%{GLOBAL}

  etc

This way you can get rid of the WSGIProcessGroup and
WSGIApplictionGroup directives altogether as you are binding what to
use in the WSGIScriptAlias directive.

Also, do not that using process-group/application-group together on
WSGIScriptAlias will also have a side effect of causing the WSGI
script file to be preloaded when process starts. A good thing from
doing that is that process likely will be ready to handle request when
first arrives, rather than application loading on first request. Since
TG is really fat its load times can be quite large and so if can avoid
delay on first request is a good thing.

Note, those two options to WSGIScriptAlias requires mod_wsgi 3.X.

Graham

> Cheers,
> (A very happy) Yannick
>
> On Jul 8, 1:10 pm, yannick <[email protected]> wrote:
>
>
>
> > On Jul 8, 12:40 pm, "Diez B. Roggisch" <[email protected]> wrote:
>
> > > On Wednesday, July 07, 2010 18:31:27 yannick wrote:
> > > > Hello all,
>
> > > > We are trying to deploy several TG2 applications behind a single same
> > > > Apache server, with mod_wsgi. Using modwsgi_deploy worked pretty well,
> > > > and the point we are at now is the following:
> > > > - each application works fine on its own behind paster and/or apache
> > > > w/ mod_wsgi
> > > > - when accessing one application, then the other always produces the
> > > > error shown below for the second application, whatever the order is
> > > > done in. As long as we stay on one given app, there doesn't seem to be
> > > > a problem. However as soon as we switch app, the problem arises and
> > > > won't go away until we reload apache. Both apps are very similar in
> > > > the way they use permissions and sqlite DBs, and present the same
> > > > error after being loaded after the other.
>
> > > > We didn't try to setup anything using virtualenv, just installed the
> > > > TG2 apps directly on the system (system-wide). The error seems to
> > > > indicate there is a conflict of columns in the DB but both apps are
> > > > configured to use separate sqlite files so I don't see how this could
> > > > be causing the problem.
> > > > If you had any insight on what might be causing this very weird issue,
> > > > I would be very very grateful.
>
> > > IMHO your decision to not use venvs is a mistake, but that's unrelated to 
> > > the
> > > problem at hand.
>
> > > What I think is the issue (Graham undoubtedly will have more insight into
> > > this) is that your setup shares one python interpreter, instead of 
> > > isolating
> > > these.
>
> > > There is ample documentation about that on the mod_wsgi-site, I think 
> > > "Daemon
> > > Processes" is the thing to look for.
>
> > > For example, our VHost setup looks like this:
>
> > >         WSGIDaemonProcess www processes=10 threads=1 python-
> > > path=/var/lib/ableton/live/lib/python2.5/site-packages
> > >         WSGIProcessGroup www
>
> > >         WSGIScriptAlias "/"    "/var/lib/ableton/live/app.wsgi"
>
> > > We have a second one, preview instead of www, which runs without a hitch.
>
> > > Diez
>
> > I have been working for quite a few hours on this, and have tracked it
> > to the process problem indeed. It appears both my applications are
> > running in the same process group, despite the instructions I have to
> > the contrary. I do not understand this at all. To simplify to the max
> > the problem, here is what I have done. I setup two sites in apache,
> > and activated the modwsgi_deploy test scripts (test.wsgi), and added a
> > line to them. They now look like this:
>
> > def application(environ, start_response):
> >     status = '200 OK'
> >     output = 'Hello World!' + environ["mod_wsgi.process_group"]
> >     response_headers = [('Content-type', 'text/plain'),
> >                         ('Content-Length', str(len(output)))]
> >     start_response(status, response_headers)
>
> >     return [output]
>
> > Now, I linked each application to a separate test.wsgi file as so
> > (apache sites-enabled files):
>
> > Alias /qubic.backoffice/images /usr/local/turbogears/qubic.backoffice/
> > qubic/backoffice/public/images
> > Alias /qubic.backoffice/css /usr/local/turbogears/qubic.backoffice/
> > qubic/backoffice/public/css
> > Alias /qubic.backoffice/javascript /usr/local/turbogears/
> > qubic.backoffice/qubic/backoffice/public/javascript
>
> > #Here is the link to the test file
> > WSGIScriptAlias /test /usr/local/turbogears/qubic.backoffice/apache/
> > test.wsgi
>
> > WSGIDaemonProcess qubicbackoffice threads=10 processes=3 display-name=%
> > {GROUP}
> > WSGIProcessGroup qubicbackoffice
> > WSGIScriptAlias /qubic.backoffice /usr/local/turbogears/
> > qubic.backoffice/apache/qubic.backoffice.wsgi
>
> > <Directory /usr/local/turbogears/qubic.backoffice/apache>
> > WSGIApplicationGroup %{GLOBAL}
> > Order deny,allow
> > Allow from all
> > </Directory>
>
> > I did the exact same thing for the other app, changing the /test alias
> > to /test2, and all "backoffice" references to "medias"
>
> > I reload apache. Whatever order I load test and test2 in, they are
> > always appearing in the qubicmedia processgroup. However, when I look
> > in "ps aux", I have both type of processes running...
> > I can't wrap my head around where my apache config files are faulty,
> > but they obviously are!
> > I really appreciate any and all help you can give
> > Yannick

-- 
You received this message because you are subscribed to the Google Groups 
"TurboGears" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/turbogears?hl=en.

Reply via email to