Hmm, I see your point and use case. But... ;) given that there are references in the manual (and probably in reality the majority of use cases) to caching views, or db queries, etc. how about then, as an enhancement, to add an init flag to cache.redis along the lines of `die_if_server_unavailable = True` to force a halt with the traceback. Or else if set to False, fail silently and gracefully (key didn't exist behaviour, re-execute function) and let the system keep running? Obviously the flag name itself is up for debate.
Would this not provide the best of both worlds and max flexibility? If you (as the cache.redis creator) agree I'll take a stab at adding that functionality to redis_cache.py and issue a PR. On Wednesday, 6 May 2015 14:41:58 UTC+1, Niphlod wrote: > > up until now, cache behaviours in web2py are a taddle bit different than > the rest of the world. cache(s) in web2py usually mean "I'd like to compute > something huge one time only" and so the general idea is that if you need > to compute it, you should be damn sure to do so. You may also be relying on > that assumption e.g. to get a huge stream of results from an external > server that bills you if you go over the quota. > The "original retry logic" is done to avoid erroring out when redis is > restarted . we may add some parameter around to change the behaviour but > since it's missing from cache.ram and cache.disk for obvious reasons.... I > don't know how much traction it could get. > > On Wednesday, May 6, 2015 at 2:33:51 PM UTC+2, Jose C wrote: >> >> Greetings, >> >> I have always assumed that if cache is unavailable, then the fallback is >> to serve the content from original source again (i.e. treat as if key does >> not exist). >> >> I was surprised today when I got a ConnectionError tracebacks when the >> redis server was not online. Checking the source it appears this is by >> design - it retries connecting 5 times over a total period of 30 seconds >> (!) before giving up and issuing the traceback. >> >> Question: Is this the default expected behaviour (grind to a halt with a >> traceback) or just an oversight? My thinking is that cache.redis should >> fallback gracefully and respond as if the key never existed when it cannot >> connect to the redis server. Certainly it should log a warning or error as >> well, but not bring the site down effectively. >> >> I know I can wrap all cache calls in try: except: blocks to trap for that >> error, however that seems extreme and the more elegant solution would be to >> handle it within cache.redis itself. >> >> Incidentally, blocking a thread for 30 seconds while waiting for the >> redis server also seems like overkill. Surely if redis hasn't responded >> within 5 seconds max it's time to move on? >> >> Thoughts? If I'm not missing something I'm happy to open an issue on >> github. >> >> web2py ver: 2.10.4 >> >> Regards, >> Jose C >> >> -- 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.
