Last modified: 2014-11-17 09:21:35 UTC
Currently importing only the top revision using transwiki import fails for no good reason I can come up with - and in fact fails more often than it succeeds. This shouldn't happen. The reason importing many revisions fails, is: "The slow part is loading the required data from external storage, but even if it sped it up by, say, 5 times, it would still time out because some transwiki jobs are just that big... to transwiki a page it might have to load up hundreds of megabytes of data from various hard drives - non-contiguous data, it'll have to seek." (Tim Starling) - but that doesn't apply to fetching only one revision, I hope. So, something must be going wrong here.
Transwiki importing times out very easily :( If the server takes too long to build the XML, the connection will time out. If it's too big, it might time out. Or if it's just transferring slowly (too much network congestion?) it might time out. Short of rethinking the interwiki imports (which might be nice), the easiest solution is making $wgHTTPTimeout higher than the default 3 seconds and being patient.
(In reply to comment #1) > Transwiki importing times out very easily :( If the server takes too long to > build the XML, the connection will time out. If it's too big, it might time > out. Or if it's just transferring slowly (too much network congestion?) it > might time out. > > Short of rethinking the interwiki imports (which might be nice), the easiest > solution is making $wgHTTPTimeout higher than the default 3 seconds and being > patient. > All true, but for *one revision* there should be no problem. We load pages for viewing (ie the top revision only) fast enough; why can't we generate xml for the same data fast enough?
Is this process still unreliable?
Transwiki importing? Yes.
