https://bugzilla.wikimedia.org/show_bug.cgi?id=45877
Krinkle <krinklem...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tstarl...@wikimedia.org
--- Comment #6 from Krinkle <krinklem...@gmail.com> ---
(In reply to Krinkle from comment #5)
> The different relevant scenarios:
>
>
> 1) index.php server first, load.php server second
>
> (..)
>
> 2) index.php server and load.php/startup first, load.php/module second
>
> (..)
3) server is in frankenstein state
This affects both ResourceLoader (load.php) and the main MediaWiki request
handling in general. Due to how we use rsync I believe it is indeed possible
for any moment during the sync action for the mediawiki install to contain
files it shouldn't, miss files it needs, and has mixed newer and older versions
of some files.
The window for this is relatively small as it relates to a single server as
opposed to the entire cluster.
This can lead to random PHP errors (which are not as visible since those aren't
cached, but they do get served to the public, mostly logged-in users only I
think, unless a page gets purged of course).
This can lead to responses from load.php that will be cached and can be making
all kinds of weird concatenations between incompatible files. This might
resolve itself if the older file was synced first (next request the sync is
finished, there'll be a newer file). But if the newer file was synced first, it
won't fix itself (same as #2).
--
CC-ing Tim Starling. I discussed this with him a few months back and he had a
few thoughts on optimising scap that would shorten the window during which this
bug can occur.
--
Using a more atomic scap, we can reduce the window during which #3 can happen.
#2 can still happen though because atomic scaps only helps a single server
maintain its state, between servers there will still be many seconds 1-2
minutes delay depending on how long the sync action takes across the cluster.
With something like git-deploy will mitigate both.
For #3:Near impossible because it works with working copies (fetch internally
first, then check out)
For #2: It first instructs all servers to fetch, and when finished all of them
to checkout. So there's much shorter window during which difference servers
have different active directories because copy time is taken out of the
equation
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
