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.