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 [email protected]. For more options, visit https://groups.google.com/d/optout.
