Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.This was initially added by beejeebus in #2248767-53: Use fast, local cache back-end (APCu, if available) for low-write caches (bootstrap, discovery, and config) and approved by catch in #2248767-62: Use fast, local cache back-end (APCu, if available) for low-write caches (bootstrap, discovery, and config), but I'm splitting it into a separate issue, because an arbitrary TTL can introduce random test failures based on how fast testbot happens to be (see #2248767-112: Use fast, local cache back-end (APCu, if available) for low-write caches (bootstrap, discovery, and config)).
Do we want a TTL, or would we prefer long running processes to call reset() at the points that they control? AFAIK, HEAD doesn't have a TTL for any other static cache, but that shouldn't rule out us adding it here if we think it makes sense.
| Comment | File | Size | Author |
|---|---|---|---|
| cache-fast-ttl.patch | 2.1 KB | effulgentsia | |
Comments
Comment #1
Fabianx CreditAttribution: Fabianx commentedCatching up with the core implementation of schroedicache.
This looks great to me and checking every 300 ms on the consistent backend is fair enough, nicely encapsulated, too.
However: Should this be settable, overridable, etc. from settings, conf or somewhere else? Currently it is hardcoded and impossible to set.
Changing it is a rare use case, but might be needed when 50 ms or such is needed?
Or I actually want stale data to be returned to be consistent per request?
Do we need tests? Can we test this?
Comment #14
smustgrave CreditAttribution: smustgrave at Mobomo commentedMoving to PNMI
For followup in questions in #2. If this is still needed.
Comment #16
smustgrave CreditAttribution: smustgrave at Mobomo commentedIf still a valid task please reopen updating issue summary and address #2
Thanks!