On 15/06/2013, at 2:45 AM, Josh Nathanson <[email protected]> wrote:
> > > > On Thu, Jun 13, 2013 at 9:19 PM, Graham Dumpleton > <[email protected]> wrote: > > On 14/06/2013, at 2:59 AM, Josh Nathanson <[email protected]> wrote: > >> >>> >>> Here you go: >>> WSGIPythonHome /path/to/python >>> WSGIDaemonProcess my_app processes=4 threads=2 display-name=my_app >>> python-path=/python/path/to/modules >>> WSGIProcessGroup my_app >>> WSGIScriptAlias /my_app /path/to/main.wsgi >>> >>> <Location /my_app > >>> WSGIProcessGroup my_app >>> </Location> >> >> Change all this to: >> >> WSGIDaemonProcess my_app processes=4 threads=2 display-name=my_app \ >> python-home=/path/to/python python-path=/python/path/to/modules >> >> WSGIScriptAlias /my_app /path/to/main.wsgi \ >> process-group=my_app application-group=%{GLOBAL} >> >> If this is the only WSGI application you are running, also add: >> >> WSGIRestrictEmbedded On >> >> >> Graham this worked! Thanks so much! >> >> I am on mod_wsgi 3.4. >> >> I did have to make one small tweak though to get it to work as needed. I >> changed application-group from %{GLOBAL} to the same name as process-group. >> I found that when it was ${GLOBAL}, there were strange clashing python >> errors, where it seemed like the 4 apache processes were not running >> independently of each other, at least on Apache startup - perhaps this is >> the intended behaviour? > > Unless you had delegated some other WSGI application to run in that daemon > process group and also in the main interpreter, there should not have been a > clash. What were the errors? > > I'm using SQLAlchemy ORM, and the error indicates that the same code to > create a table is being run multiple times in the same context (I think) - > initializing this code is part of the main() function that runs on apache > startup.. I do not see the below errors on apache startup when I use > application-group=my_app instead of application-group=${GLOBAL}. > > [Fri Jun 14 09:03:00 2013] [error] mod_wsgi (pid=19760): Target WSGI script > '/am/apps/slp/taccit/test/courses_controller/main.wsgi' cannot be loaded as > Python module. > [Fri Jun 14 09:03:00 2013] [error] mod_wsgi (pid=19760): Exception occurred > processing WSGI script > '/am/apps/slp/taccit/test/courses_controller/main.wsgi'. > File > "/am/apps/other/python/2.6.6/Linux.x86_64/lib/python2.6/site-packages/sqlalchemy/engine/default.py", > line 324, in do_execute > [Fri Jun 14 09:03:00 2013] [error] cursor.execute(statement, parameters) > [Fri Jun 14 09:03:00 2013] [error] ProgrammingError: (ProgrammingError) > ('42S01', "[42S01] [FreeTDS][SQL Server]There is already an object named > 'taccit_courses' in the database. (2714) > (SQLExecDirectW)") '\\nCREATE TABLE taccit_courses (\\n\\tid INTEGER NOT NULL > IDENTITY(1,1), \\n\\tname VARCHAR(256) NULL, \\n\\tdefinition_id VARCHAR(256) > NULL, \\n\\tstart_date DATETIM > E NULL, \\n\\tPRIMARY KEY (id)\\n)\\n\\n' () Why is the code run on process startup doing table creation? Even if the code is trying to check whether tables exist and so whether it is required, it can fail in any multi process configuration because there is no synchronisation across processes. Specifically, a process could check to see if tables exist and find they done, but before it gets to create them, another process could have created them. Creating tables when web process starts, or at any time in the web process looks dangerous. >> In my case I do not want them to share anything between each other. Also, >> with the ${GLOBAL} setting, it seemed like main.wsgi was being executed on >> EVERY request rather than just on startup; again, perhaps this is the >> intended behavior when using ${GLOBAL}. > > The only way that might happen is that there was an error on importing the > module, but if that was the case you would get a 500 error response on every > request and there would be error messages all through the logs. > > Yes, the error above indicates there is an error when importing the module. > Then every request thereafter throws a 500 error as you say. > > I should probably also mention that these WSGI directives are placed within > VirtualHost blocks in the main Apache config file. The reason is that we are > serving multiple apps from the same servername but different ports. So we > need separate VirtualHosts for each wsgi app. However, each one does have > its own separate process group within the VirtualHost block. The request > urls might look like so: > > http://somehost.com/my_app1 -- process-group=my_app1 > http://somehost.com:8088/my_app1 -- process-group=my_app1_test > http://somehost.com/my_app2 -- process-group=my_app2 > http://somehost.com:8088/my_app2 -- process-group=my_app2_test > > > > If you aren't going to set application-group to %{GLOBAL}, you may as well > not set it and let it use it default. > > > > OK, I removed application-group entirely, and I again got the desired > behavior - the app is loaded up successfully on apache startup, with no > errors. I thought application-group was required to not lazy-load the > application? Or is it just adding the process-group to the WSGIScriptAlias > directive enough to do that? Ah, forgot you wanted preloading. To have preloading be side affect of the definition, application-group is required. I still can't see why %{GLOBAL} itself is the cause of the issue and rather than the fact you creating tables at all just looks dodgy. Care to explain more about what it is creating tables for and what is being done to protect this when you have a multi process configuration. Graham -- 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.
