thibaultcha
Cache lock timeout handling
In the current implementation, a cache lock timeout is treated as an error.
As mentioned in README, cache lock is "to prevent dog-pile effects". It is an optimization. Cache lock timeout itself shouldn't be a cause of error. A common way of handling cache lock timeout, for example, nginx cache lock timeout, is just to perform uncacheable lookup, similar to elapsed cache lock.
Let's talk about it before I start to try to make a change, since it could also be a breaking change.
Right, and yet that is not the only the purpose the cache lock serves though; quite often when I have seen this lock expire it has been because of the elected callback itself timing out (i.e. DB timeouts, DNS issues, ...). In such cases, it is much more useful to have an option like resurrect_ttl and early-exit all pending lookups rather than risking cascading failures.
When I hear similar concerns as yours on how to tweak the lookup mechanism to your needs, I think about a configurable retry policy mechanism for this library, a step beyond resurrect_ttl, which could be quite elegant and allow for finer pre-built policies such as the one you described.
