Hi, thank you both for your time and concern.
@Richard: this particular website was still running with sessions stored in
Redis. As we have several websites, moving sessions to Redis is something
that we will do progressively in the next weeks.
@Anthony: the database server is PostgreSQL, running in the same VPS, so I
wouldn't say it's due to network problems. I do have pgBouncer and I limit
the pool size to only 1 connection (with 2 of reserve pool) per database.
The app didn't have much load (actually it almost never has), but in this
situation, with that query hanging for 60 seconds, it's probable that the
ticket error was because there were no more connections available for that
db (for example, if the user with the problem tried simultaneously in a
laptop, in a pc and in his mobile phone).
Some (weird) points about the problem:
- While it presents in an specific account, other user accounts can
login and work perfectly with the app.
- As an admin, I have the permission to impersonate other user accounts.
When the problem happens, I can impersonate any account but the one with
the problem (the impersonation is successfull, but the same timeout
presents after I'm impersonating the account).
- Problem doesn't go away deleting all web2py_session_table records and
clearing cookies.
- Problem doesn't go away changing the account email or password.
- The only solution I've been applying last times it happened, was to
create a new account for the user and invalidate the old one.
Today, when the problem happened, I created the new account for the user
and moved the sessions to Redis. Maybe I should have kept sessions in the
db, in order to debug the problem with that account. Now it's not possible
anymore, because I already moved to Redis. Of course I could move back
sessions to db, but I don't like the idea of debugging at production in the
website of a customer, specially one who had a recent issue with this.
So, I'll wait if it happens again, and I'll try to leave the account there
to do some tests.
Thank you very much for your time!
El lunes, 16 de abril de 2018, 17:31:47 (UTC-3), Anthony escribió:
>
> 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 web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
