Thank you for your fast answer Anthony! You are right, the problem is fixed in master. I applied those changes and the problem was solved.
Thank you very much! El miércoles, 6 de junio de 2018, 10:44:42 (UTC-3), Anthony escribió: > > I believe this has been fixed in master: > https://github.com/web2py/web2py/commit/ea5ea6a30759a2c825f23381540dc396cbc475b7 > . > > Anthony > > On Wednesday, June 6, 2018 at 9:16:57 AM UTC-4, Lisandro wrote: >> >> Quick update: *apparently the problem doesn't happen using >> RedisCache(with_lock=False, ...)* >> Should this be considered a bug or is it the expected behaviour? >> >> I would like to keep with_lock=True but avoid that 10 second delay when a >> function raises HTTP 503 or 404. >> The issue with that delay is that, during that time, the request is using >> a database connection, and in my environment I have the risk of exhausting >> db connections. >> >> I'll try to play a bit with the source code of redis_cache.py, but still >> any suggestion or comment will be much appreciated. >> Thanks! >> >> El miércoles, 6 de junio de 2018, 9:45:55 (UTC-3), Lisandro escribió: >>> >>> Hi there! I recently upgraded my production environment to web2py >>> 2.16.1, and I'm facing an old issue that was apparently solved. >>> In my applications I use @cache.action to cache public pages, and as I >>> use Redis for cache, I use it like this: >>> >>> @cache.action(time_expire=300, cache_model=cache.redis, session=False, >>> vars=False, public=True) >>> def test(): >>> .... >>> >>> >>> Well, I've found that, *when the function raises an HTTP 503 or 404, it >>> takes 10 seconds to complete and return the result*. >>> Now, this only happens when cache_model=cache.redis. >>> *If I change it to cache_model=cache.ram, it takes a few milliseconds to >>> complete as expected.* >>> >>> I'm using Redis 3.2.10 64bit on CentOS7. >>> The problem had been reported long time ago, and it was also fixed: >>> https://github.com/web2py/web2py/issues/1355 >>> >>> I've checked my web2py source code, and it's indeed using the latest >>> stable version 2.16.1, and just in case, I looked at >>> gluon/contrib/redis_cache.py and the fix is there. >>> However, it appears that the problem still can be reproduced with this >>> code: >>> >>> from gluon.contrib.redis_cache import RedisCache >>> from gluon.contrib.redis_session import RedisSession >>> from gluon.contrib.redis_utils import RConn >>> >>> _redis_conn = RConn('localhost', 6379) >>> cache.redis = RedisCache(redis_conn=_redis_conn, with_lock=True) >>> >>> @cache.action(time_expire=300, cache_model=cache.redis, session=False, >>> vars=False, public=True) >>> def test(): >>> raise HTTP(503) >>> >>> >>> Notice that it always takes 10 seconds, maybe that should bring in some >>> clue about what's happening. >>> Any suggestion? >>> >>> Thanks in advance! >>> Regards, Lisandro >>> >> -- 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.
