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