[web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

I just wanted to confirm that the problem was apparently solved after upgrading web2py to version 2.16.1 and also upgrading Redis to latest stable 64bit version (version 1.8.1). The app has been running for a couple of weeks now and the problem didn't arise. I truly sorry having bothered you wit

[web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

That is a very old version of web2py. The problem may have been solved years ago. ;-) On Thursday, 3 May 2018 16:37:53 UTC-5, Lisandro wrote: > > I came back to reply this particular message, because the problem happened > again yesterday. > > Just in order to remember, the problem was with redi

[web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

> > I'm using an old web2py version (Version > 2.10.3-stable+timestamp.2015.04.02.21.42.07). > I already have plans to upgrade. > But before, could I manually update only gluon/contrib/redis_*.py files? > In your opinion, does that test worthwhile? Does it make any sense? > I haven't studied th

[web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

I came back to reply this particular message, because the problem happened again yesterday. Just in order to remember, the problem was with redis_cache.py failing to write some specific key name. Not *__lock object was found in the cache during the incident. Connecting manually to redis-cli woul

[web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

El sábado, 21 de abril de 2018, 18:00:36 (UTC-3), Anthony escribió: > > A quick comment about a couple of tests I did regarding RedisSession (that >> also has a "with_lock" argument). >> To the test, I updated web2py locally to version >> 2.16.1-stable+timestamp.2017.11.14.05.54.25 >> And then I

[web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

> > A quick comment about a couple of tests I did regarding RedisSession (that > also has a "with_lock" argument). > To the test, I updated web2py locally to version > 2.16.1-stable+timestamp.2017.11.14.05.54.25 > And then I run my apps using: > >- RedisSession(..., with_lock=False) >Thi

[web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

Ok, I've left it set to True. A quick comment about a couple of tests I did regarding RedisSession (that also has a "with_lock" argument). To the test, I updated web2py locally to version 2.16.1-stable+timestamp.2017.11.14.05.54.25 And then I run my apps using: - RedisSession(..., with_lock=

[web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

On Friday, April 20, 2018 at 11:58:47 AM UTC-4, Lisandro wrote: > > I see what you mean. > But still, if my interpretation is correct, in those cases we should see > the *__lock key stored. > What is weird about my specific issue is that there was no *__lock key. > > Anyway, regardless upgrading

[web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

I see what you mean. But still, if my interpretation is correct, in those cases we should see the *__lock key stored. What is weird about my specific issue is that there was no *__lock key. Anyway, regardless upgrading web2py, now I'm wondering if I should set with_lock True or False. Do you ha

[web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

On Friday, April 20, 2018 at 10:47:10 AM UTC-4, Lisandro wrote: > > Thank you very much for your time Anthony. > > Yes, I use Redis with_lock=True. > I checked but there is no *__lock key stored in Redis. I double checked > that. > > But, giving you mentioned with_lock, I tried to set with_lock=Fa

[web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

Thank you very much for your time Anthony. Yes, I use Redis with_lock=True. I checked but there is no *__lock key stored in Redis. I double checked that. But, giving you mentioned with_lock, I tried to set with_lock=False, and it worked. Then I set with_lock=True again, and it worked too. *App

[web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

When you set up the Redis cache, do you set with_lock=True? If so, I wonder if an error here could be causing the key to be locked and never released. I guess you can check for a

[web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

Sorry to bother you again with this, but I think I've found the problem. *The problem is apparently with Redis integration. *It had nothing to do with connections, database, sessions, none of that. Here is what I've found. Remember, the line where my app hangs is this: *session.important_message

[web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

Hi there, I've found the issue but I still don't know how is it produced. Anthony was right from the begining when he said "the app is not hanging because the locks are being held, but rather the locks are being held because the app is hanging" Since that comment, I was waiting for the problem to

[web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

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, runni

[web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

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,

Re: [web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

Hello LIsandro, I recall you have ask question about session in redis... Could there are remaining stuff of experiment with redis that haven't been commented out completly?? Richard On Mon, Apr 16, 2018 at 3:15 PM, Lisandro wrote: > Hi there, sorry to bother again, I have some additional info

[web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

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"

[web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

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

[web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

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_u

[web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

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. F

[web2py] Re: Web2py locks row at auth_user and web2py_session_* tables and doesn't unlock them

For any select that takes place within a transaction, Postgres by default automatically acquires a access share lock on the involved tables, so this should be happening on all requests. However, access share locks do not conflict with each other, so I don't think these locks are necessarily the