Hi there, sorry to bother again, I have some additional info that could
help.
The problem happened again, exactly the same as the other times.
But this time an error ticket was created with this traceback:
-
Traceback (most recent call last):
File "/var/www/medios/gluon/main.py", line 463, in wsgibase
session._try_store_in_db(request, response)
File "/var/www/medios/gluon/globals.py", line 1152, in _try_store_in_db
if not table._db(table.id == record_id).update(**dd):
File "/var/www/medios/gluon/packages/dal/pydal/objects.py", line 2117, in
update
ret = db._adapter.update("%s" % table._tablename,self.query,fields)
File "/var/www/medios/gluon/packages/dal/pydal/adapters/base.py", line
988, in update
raise e
DatabaseError: query_wait_timeout
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Could this indicate that for some reason web2py is failing to store the
session?
Or could it still be that a deadlock in my app code is producing this error?
El viernes, 6 de abril de 2018, 18:59:28 (UTC-3), Lisandro escribió:
>
> Oh, I see, you made a good point there, I hadn't realised.
>
> I guess I will have to take a closer look to my app code. Considering that
> the problem exists in specific accounts while others work ok, and
> considering also that the problem happens with any request that that
> specific user makes to any controller/function, I'm thinking: what does my
> app do different for a user compared to another one at request level? For
> "request level" I mean all the code the app runs in every request, to
> start, the models/db.py
>
> I'll take a closer look to that and will post another message here if I
> find something that could signal the root cause of the issue.
>
> Thank you very much for your help!
>
>
>
> El viernes, 6 de abril de 2018, 16:05:13 (UTC-3), Anthony escribió:
>>
>> On Friday, April 6, 2018 at 10:58:56 AM UTC-4, Lisandro wrote:
>>>
>>> Yes, in fact, I've been running that SQL command to check for locks, and
>>> sometimes I see that lock on other tables, but that other locks live for
>>> less than a second. However, when the problem happens, the lock on the
>>> auth_user and web2py_session tables remains there for the whole 60 seconds.
>>>
>>
>> Yes, but that doesn't mean the lock or the database has anything to do
>> with the app hanging. The locks will be held for the duration of the
>> database transaction, and web2py wraps HTTP requests in a transaction, so
>> the transaction doesn't end until the request ends (unless you explicitly
>> call db.commit()). In other words, the app is not hanging because the locks
>> are being held, but rather the locks are being held because the app is
>> hanging. First you have to figure out why the app is hanging (it could be
>> the database, but could be something else).
>>
>> Anthony
>>
>
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
