Hi Massimo, thank you for your time. I had marked this thread as "no action needed" because I found the cause of the issue.
First I thought it was a different problem, so I opened a new thread in this forum: https://groups.google.com/forum/#!topic/web2py/E9jrmf5E-B4 The title of that thread is not correct. I ended up finding that the problem is generated in some specific situations, and a specific key can't be stored at redis cache. In that thread I've posted some details about the tests I made to figure out that was the root cause. Sorry if I created some confusion opening a new thread, won't happen again :) El martes, 24 de abril de 2018, 18:43:09 (UTC-3), Massimo Di Pierro escribió: > > That query itself cannot case hanging but maybe when that query is > executed the database is busy with some other background task? > Try setting migrations to false. may be you are doing more database IO > than you should > > On Friday, 6 April 2018 09:41:09 UTC-5, Lisandro wrote: >> >> Hi Anthony, again, thank you very much for your time, I really appreciate >> it. >> >> El jueves, 5 de abril de 2018, 17:52:36 (UTC-3), Anthony escribió: >>> >>> On Thursday, April 5, 2018 at 2:57:20 PM UTC-4, Lisandro wrote: >>>> >>>> Thank you Anthony, yes I'm aware of that. >>>> I use it like that for this reason: sometimes (not very often) an >>>> external app modifies a field of the auth_user table (specifically, it >>>> sets >>>> true or false a field that I use as a flag). However that change isn't >>>> updated to auth.user. In order to do so, the user needs to logout and >>>> login >>>> again. So I retrieve the auth_user record again and store it to >>>> response.answer. >>>> >>>> Maybe it could be done like this: >>>> if auth.is_logged_in(): >>>> auth.user = db.auth_user[auth.user.id] >>>> >>>> But I thought it could be break something with Auth methods, so I store >>>> it in response.user. >>>> >>> >>> Got it. Yeah, don't replace auth.user -- create a separate variable. >>> >>> >>>> Anyway, I set this topic as "no action needed" because I opened a new >>>> topic, I've found some more info and I think the issue isn't related to >>>> that sentence. >>>> >>> >>> But you indicated the select generated by that code was causing Postgres >>> to hang. Are you sure that is the case? In other words, is the web2py code >>> getting stuck at that line and ultimately causing your server to time out? >>> Have you tried adding some logging statements to your code to determine >>> exactly where it is getting stuck? >>> >> >> To be truth, I'm not exactly sure that is the line where the code hangs, >> I supposed that because of the select query taking too long, but I can't be >> sure. >> The problem is that the incident presents sporadically, and the worst >> part is that I can't reproduce it. Also, as it happens in the production >> server, I can't afford to modify the app code in production, giving that I >> would be making changes to an application that is used by our customers, so >> I'm in a tricky situation. >> >> I've made have plans to move sessions to Redis, but as a developer, I >> would still like to understand the root cause of the issue :) >> >> Anyway, I'll wait to the incident happens again, hoping that it happens >> in an app of a "small" customer so I can do some tests. >> >> >> >> >>> >>> 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.