cache2-stale-while-revalidate interaction with worker process restarts

Question

uwsgi cache2 provides per-process key-value storage with a documented 'expires' parameter for time-bound entries; absent an explicit setting, items persist until the hosting worker process restarts. Version 2.0.10 added the 'cache2-stale-while-revalidate' flag to control stale entry serving during background revalidation, but how this flag interacts with worker process restarts across a deployment remains unspecified.

Because each uwsgi worker process maintains its own independent cache2 instance, stale entry behavior is not shared or synchronized between workers unless an external store such as Redis is deployed. The undocumented interaction between cache2-stale-while-revalidate and per-process restart cycles raises questions about whether stale serving resets, persists, or becomes inconsistent depending on which worker handles a given request.

Does the cache2-stale-while-revalidate window reset to zero when a worker process restarts, or does it retain a relative timeout from the original entry insertion?
When multiple worker processes serve requests for the same application, can stale entries be served inconsistently depending on which worker handles the request, and if so, what configuration mitigates this without resorting to an external cache?
How does the cache2-stale-while-revalidate behavior differ between uwsgi 1.9.x and 2.0.x, given the documented version-dependent variance?

Muntasir · Answer

Direct AnswerWhen a uWSGI worker restarts, the cache2-stale-while-revalidate window resets to zero because the entire cache2 instance is destroyed and recreated empty. This causes inconsistent stale-serving behavior across workers: a non-restarted worker may still serve a stale entry during background revalidation, while a restarted worker sees a complete cache miss and triggers a fresh fetch.Confirmed FactsEach uWSGI worker maintains an independent cache2 instance with no inter-worker synchronization.Worker process restart destroys all cache2 data; no persistence exists by default.The cache2-stale-while-revalidate flag (uWSGI 2.0.10+) enables serving expired entries while background revalidation runs.In uWSGI 1.9.x, this flag does not exist; stale serving during revalidation is unavailable.ExplanationThe stale-while-revalidate window is calculated from the entry's insertion timestamp. On restart, the entry itself vanishes, so the window cannot be preserved. Requests routed to different workers post-restart will see different cache states: one worker might serve stale content while another fetches fresh data, creating user-visible inconsistency.Mitigation StepsDisable stale-while-revalidate by setting cache2-stale-while-revalidate=0 to ensure consistent miss/fetch behavior across workers.Use a short expires value (shorter than typical worker restart intervals) so entries expire before restarts occur, ensuring all workers see the same state.Deploy an external cache (Redis, Memcached) for shared state across workers if stale serving consistency is critical.Version DifferencesuWSGI 1.9.x lacks the stale-while-revalidate flag entirely. Entries are either fresh (within expires) or expired (triggering immediate fetch). The 2.0.10+ flag introduces the ability to serve stale content during async revalidation, making restart-related inconsistency possible where it wasn't before.

cache2-stale-while-revalidate interaction with worker process restarts

1 answer

Direct Answer

Confirmed Facts

Explanation

Mitigation Steps

Version Differences

Your perspective belongs here.

0 question comments