On Sat, Jun 15, 2013 at 9:55 PM, Graham Dumpleton < [email protected]> wrote:
> > 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_idVARCHAR(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 > > Graham, I think the table creation is kind of a red herring. To try and test what was going on, I commented out all the code in the main function of the python application, and just put a print statement "in main function." When I added application-group= ${GLOBAL}, it printed the statement 8 times on startup, twice for each process. When I removed application-group=${GLOBAL}, it printed the statement 4 times on startup, once for each process. In both cases the application preloaded, contrary to your statement that adding application-group was required for preloading. Is this what you would expect to see? -- Josh -- 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.
