Hello all,
a question about web2py and concurrent requests on GAE - I'm seeing some
odd behavior and i would like to know if my theory is at all reasonable,
and suggestions for testing my theory. an RTFM (read the friggen manual)
response is just fine - can you point me to the manual?
my assertion: on GAE web2py puts per-request items into the shared global
namespace, such as db and auth. this causes problems on GAE with
concurrency enabled because data gets clobbered.
why do i believe this? well, i turned on concurrency (threadsafe: true) in
app.yaml and after some time as the site gets loaded with real users (i
have not run into this when testing probably because i don't generate
enough test traffic) i see errors like:
File
"/base/data/home/apps/s~myapp/default-30a0bc01f698.356965928401701861/applications/myapp/controllers/admin_stores.py",
line 10, in <module>
auth.settings.actions_disabled=['profile', 'change_password']
NameError: name 'auth' is not defined
AttributeError: 'auth_user' object has no attribute 'preferred_store'
File
"/base/data/home/apps/s~myapp/default-30a0bc01f698.356965928401701861/applications/myapp/controllers/order.py",
line 12, in <module>
db.store.virtualfields.append(StoreVirtualFields())
NameError: name 'db' is not defined
File
"/base/data/home/apps/s~myapp/default-30a0bc01f698.356965928401701861/applications/myapp/controllers/food.py",
line 22, in menu
response.title = response.title + " - Our Menu"
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
i'd love to prove or disprove my theory that what is happening is that
while the request that errors is being processed, db.py (and menu.py) is
being evaluated for a second request, essentially clearing variables like
db, auth, and perhaps even response (the None response.title when
response.title is set in menu.py is most concerning).
i admit to not fully understanding how the run_X_in_environment(), and
build_environment() and python variable scoping works well enough to know
if my theory is valid and how best to test my theory? i've thought about
putting a sleep in db.py just to see if i can reliably re-create this type
of behaviour.
any thoughts?
thanks,
christian
