If we're populating the cache from GET requests/slave DB, then that means we're not calling set in the POST requests. This will be a problem if we're reading the cache later in the POST request (not only will it not be in in-process cache, it won't be in memcached at all).
We need to find a solution to this.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T128228 Improve how transactions work for board moves | |||
| Resolved | aaron | T88445 MediaWiki active/active datacenter investigation and work (tracking) | |||
| Resolved | SBisson | T120009 Flow: Use WAN cache delete() and replica-based filling to avoid merge() | |||
| Resolved | SBisson | T120008 Remove in-process Memcached wrapper or find an appropriate solution for cross-DC world | |||
| Open | None | T120007 Add debug/warn for cache reads from in-process Memcached cache wrapper |
MediaWiki core and extensions use of objectcache has mostly been converted to embrace WANObjectCache. Part of its core design is that everything is slave-only. Primarily with performance, scalability and cross-DC in mind.
Given the wide range of use cases it has fulfilled thus far, I think it's unlikely Flow needs to use master during GET requests nor for populating caches.
It's a very different cache model to get used to (perspective of cache on get and purge on set, rather than cache on set and replicate). I'm happy to sit down and help map it to current Flow methods if you have any questions.
Hi Stephane, Triage team believes this may be fixed by the thing you're working on. That's why it's assigned to you. Is that so?
Yes, we hope that is gong to be fixed at the same time as T120009: Flow: Use WAN cache delete() and replica-based filling to avoid merge(), which is the one I'm working on.