Wikimedia Bugzilla is closed!

Which step did this happen? (I would assume on the upload first ten files for preview)?

is a stack trace available?
GWToolset doesn’t call LinksUpdate::updateLinksTimestamp directly. 

searching through the core code it looks like this is called when a deferred 
update is run, so is this:

• a deferred update issue?
• a coincidental db issue at the moment this use of GWToolset ran?

LinksUpdate::updateLinksTimestamp
LinksUpdate::doIncrementalUpdate
LinksUpdate::doUpdate

also an instance of LinksUpdate seems to be created and a doUpdate run for:
ParserOutput::getSecondaryDataUpdates
WikiPage::doCascadeProtectionUpdates

(In reply to Bawolff (Brian Wolff) from comment #1)
> Which step did this happen? (I would assume on the upload first ten files
> for preview)?

yes, i confirm

Using the GWtoolset, I experiment different kind of timeout error.

As I can remember, 3 kinds of timeout happened.
- the first is described below
- the second is a blank screen with a black line. Error 504 [...] something gateway [...] timeout
- the last kind is the upload icon that turn again and again.

I will try to keep screenshot next time I try to use the tool.

How often would you say these various types of errors occur?

The second (and possibly third) may be correlated with how big the files uploaded during the preview stage are.

• is this related to bug 63864?
• if related, this may have to do with the mediafile file size.
• fyi: the default preview should only upload the first 3 items
  in the metadata file.

(In reply to dan from comment #6)
> • is this related to bug 63864?
at first glance i would say no, or at least not enough evidence to draw a conclusion. (Unless the job also is failing for a db lock timeout. Alas i dont have access to logs so have no idea why the jobs didnt go).

> • if related, this may have to do with the mediafile file size.

Bigger files do have a tendency to expose bugs that are sometimes not shown on small files

> • fyi: the default preview should only upload the first 3 items
>   in the metadata file.

(In reply to dan from comment #6)
> • is this related to bug 63864?

When I don't have the bug 63818 (timeout pb) and when I obtain finally the 4th (and last) step of the upload process, I get the bug 63864.

> • if related, this may have to do with the mediafile file size.
> • fyi: the default preview should only upload the first 3 items
>   in the metadata file.

(In reply to Bawolff (Brian Wolff) from comment #5)
> How often would you say these various types of errors occur?
> 

4 or 5 times before I obtain the bug 63864.
And I'm patient.

> The second (and possibly third) may be correlated with how big the files
> uploaded during the preview stage are.

I did'nt think, there could be pbs with the size of the files.
So I made a lot of tests for the datamapping and remote upload with jpg a. But I did'nt with the tif files on the beta cluster :\ Sorry

A new test this morning :

For the logs, the same bug at about 9:20 am (Paris)
    Fonction : LinksUpdate::incrTableUpdate
    Erreur : 1205 Lock wait timeout exceeded; try restarting transaction (10.64.16.29)

Reload the page a second time : same result.

And at the third time, I complete the step 3, and obtain previsualisation of 3 pictures (2 of this was uploaded before)

No problem to go to the step 4 but nothing happened like described in the bug 63864

has this patch resolved the issue https://gerrit.wikimedia.org/r/127839 ?

the patch has been deployed to production. are you okay with closing this bug now?

assuming that this is no longer an issue with https://gerrit.wikimedia.org/r/#/c/127839/ applied ...

(In reply to dan from comment #13)
> assuming that this is no longer an issue with
> https://gerrit.wikimedia.org/r/#/c/127839/ applied ...

Thanks Dan. I could not test if the problem is still there, but no worries − we'll reopen if needed ;-)