lib/cache: enforce cache.{min,max}_ttl()

Cherry-pick 776ceefa to add an option for cache.{min,max}_ttl()

Fixes #120 (closed)

assigned to @ondrej

added 2 commits

• e3271a65 - Prevent int overflow when getting new {min,max}_ttl value
• 539cb681 - Nits in the README.rst for {min,max}_ttl

Compare with previous version

Now the only drawback is that the first answer has the original TTL, but the subsequent requests has the bumped cached TTL.

The pkt is modified directly in rrcache_stash->stash_commit->commit_rr call chain, but somehow it's not used to display the result.

In fact, the cause might be the same as in #124 (closed).

added 2 commits

• 48ad6614 - Better dig cmd example in scripts/launch-test-instance.sh
• 594de930 - lib/cache: add configuration options to enforce cache.{min,max}_ttl()

Compare with previous version

Yes, I think so: after vld-refactoring the answer is formed from answ_selected and not directly from the last message.

Do we really want to return the adjusted TTL instead of the original? The #120 (closed) description suggests to return "unchanged TTL" (i.e. only decremented by the elapsed time) but drop it from cache earlier.

Does @vavrusam have any ideas how to fix that? (Or should we merge this as is and fix this later...)

@vcunat: for max_ttl it returns the unchanged TTL. But for min_ttl, you would have to return 0 as TTL for indefinite period of time and it would confuse end users if the records would not expire from cache after TTL == 0.

So in fact I think this is the correct behaviour - limit the internal timer with max_ttl, but bump the TTL with min_ttl.

Related: just today I was thinking if it's right that the hints module returns the records with TTL == 0, but I left it in the end.

@vcunat I think 0 TTL for hints is fine. (Or it might be configurable, but I would not add a feature nobody wants.)

changed milestone to %1.2.0 release

mentioned in commit ee532be2

merged