cache.redis server unavailable = traceback. Bug?

[Jose C]

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

[Niphlod]

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.

[Jose C]

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.

[Niphlod]

I was thinking about a major overhaul of the connection algorithm. Redis is improving quickly and more and more connection options are made available at each release. Both redis_cache and redis_sessions should be able to work on a "redis-like" connection object. In that rewrite I'd add this "flag" too. File a bug anyway on github so it gets tracked

[Jose C]

Ok, issue opened:
https://github.com/web2py/web2py/issues/958

Thanks Niphlod.