Require a `CacheableSource` implementation to signal whether stale
settings may be served from the cache by implementing an
`allowsStaleLoad()` method. This will be useful for sources (e.g. etcd)
that expect some degree of unavailability and failover during
unavailability is desired.
In order to support stale results, `CachedSource` sets cache items with
an indefinite TTL but uses the computed expiry timestamp in the envelope
to consider whether the item is considered expired as opposed to a true
miss where the item is malformed or not present in the cache store. If
a `SettingsBuilderException` is thrown during the source's `load()`
method but the cache check was not a real miss, the stale cached results
are returned.
Note there is currently no pruning of cache items so it is advised that
`CacheableSource` implementations for which stale loads are allowed also
implement an immutable `getHashKey()` based on constructor arguments.
Bug: T296771
Change-Id: Ida0698a237dc0939230799700b6f54956f033d50
Move cache TTL from `CachedSource` into the `CacheableSource` interface,
allowing each source to define a TTL most appropriate to its own
settings loading implementation.
Fix bug where `generation` time was computed incorrectly by `CachedSource`.
Include tests to exercise all `CachedSource` interactions with
`CacheInterface` and `CacheableSource`.
Bug: T296771
Change-Id: I97c42cf6ca716516c32104de25245aa21ec110e4
The `SettingsBuilder` now accepts a PSR-16 cache interface with which to
store and query settings before attempting to load from each source. By
default, no cache is used, but any object that implements the
`Psr\SimpleCache\CacheInterface` may be provided to the constructor.
An explicit dependency on "psr/simple-cache" has been added to
`composer.json`. Note that this dependency already existed in vendor
albeit it as a transitive one.
An APCu based `SharedMemoryCache` adapter is provided as a canonical
PSR-16 compliant interface for production use.
Sources are now queued by the `SettingsBuilder` when calling `load()`.
If a cache interface has been provided, and the source is considered
cacheable (implements `CacheableSource`), then it is wrapped as a
`CachedSource` which will query the cache first before loading from the
wrapped source.
Cache stampedes are mitigated using probabilistic early expiry. The
implementation for this was partially based on symfony/cache-contract
source code but also from the Wikipedia article and paper referenced
therein.
See https://en.wikipedia.org/wiki/Cache_stampede#Probabilistic_early_expiration
Bug: T294748
Change-Id: I52ab3899731546876ee58265bd4a1927886746dc
If php-yaml extension in installed, use that. Otherwise
we fallback to symfony Yaml parser.
php-yaml is about 20 times faster then symfony, for default-settings.yaml
it will take PHP-yaml 6ms to load it vs 100ms for symfony. But given
that the result will be cached, it's better not to bring in
a required native dependency.
Bug: T294751
Change-Id: I3ffde926c3f264cacf39810ff7bd338c9f78823d
A `SettingsSource` is meant to represent any kind of local or remote
store from which settings can be read, be this a local file, remote URL,
database, etc. It is concerned with reading in (and possibly decoding)
settings data, and computing a consistent hash key that may be used in
caching.
A `SettingsFormat` is meant to detect supported file types and/or decode
source contents into settings arrays. As of now, JSON is the only
supported format but others may be implemented.
`FileSource` is the first source implementation, with its default format
being JSON, meant to read settings from local JSON files.
`ArraySource` is mostly useful for testing using array literals.
Refactored `SettingsBuilder` methods to use the new source abstractions.
Bug: T295499
Change-Id: If7869609c4ad1ccd0894d5ba358f885007168972
