Where is the database server running? Is it possible there are occasional
network problems connecting to it?
Anthony
On Monday, April 16, 2018 at 3:15:54 PM UTC-4, Lisandro wrote:
>
> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
