Lock time outs on 10.0.0.101

List overview All Threads
Download

newer

older

IBM DB2 support for Mediawiki

extension edits twice instead of...

Bryan Tong Minh

24 Jun 2008 24 Jun '08

10:08 a.m.

Hello, I recently got a lot of lock timeouts when logging in via the API. Error message: u'internal_api_error_DBQueryError', u"Exception Caught: A database error has occurred\nQuery: UPDATE `user` SET user_name = 'BryanBot', [private data] WHERE user_id = '65821'\nFunction: User::saveSettings\nError: 1205 Lock wait timeout exceeded; Try restarting transaction (10.0.0.101)\n" The errors is always with 10.0.0.101. Bryan

Show replies by date

Roan Kattouw

26 Jun 26 Jun

3:24 p.m.

Bryan Tong Minh schreef:

...

The error seems pretty straightforward to me: the software is trying to get a lock on the user table and has to wait too long for that. Unless this is some kind of new structural problem at Wikimedia, you just have to retry your request and hope for the best. Roan Kattouw (Catrope)

Simetrical

5:55 p.m.

On Thu, Jun 26, 2008 at 11:24 AM, Roan Kattouw <roan.kattouw(a)home.nl> wrote:

...

However, this message can be symptomatic of some other problem if it occurs too frequently. It could indicate that something is slowing down queries such that they take too long (and hold locks too long). It could also mean that the API is running queries that are unnecessarily prone to locking. Or maybe misusing transactions somehow or something, I don't know. Wait a minute, though, is the API running an update on the user table every time someone logs in? If so, why? Especially UPDATE user SET user_name . . . why should anything other than Special:RenameUser be touching user_name *ever*?

Bryan Tong Minh

6:03 p.m.

On Thu, Jun 26, 2008 at 7:55 PM, Simetrical <Simetrical+wikilist(a)gmail.com> wrote:

...

Wait a minute, though, is the API running an update on the user table every time someone logs in? If so, why? Especially UPDATE user SET user_name . . . why should anything other than Special:RenameUser be touching user_name *ever*?

FYI, it was setting the whole content of the user entry again, including email and preferences etc. That is what has been replaced by [private data] Bryan

Simetrical

6:21 p.m.

On Thu, Jun 26, 2008 at 2:03 PM, Bryan Tong Minh <bryan.tongminh(a)gmail.com> wrote:

...

FYI, it was setting the whole content of the user entry again, including email and preferences etc. That is what has been replaced by [private data]

I suspected that. Something's wrong here. That query should *not* be running on Wikimedia servers, it's scary and does nothing, and causes needless locking to boot. Perhaps it's the fault of CentralAuth or something: I didn't see any suspects in the API, at a quick glance. On Thu, Jun 26, 2008 at 2:09 PM, Roan Kattouw <roan.kattouw(a)home.nl> wrote:

...

I'm pretty sure it's not meant to change user_name, it seems to be just a poorly-written query.

Bryan Tong Minh

6:32 p.m.

On Thu, Jun 26, 2008 at 8:21 PM, Simetrical <Simetrical+wikilist(a)gmail.com> wrote:

...

On Thu, Jun 26, 2008 at 2:03 PM, Bryan Tong Minh <bryan.tongminh(a)gmail.com> wrote:

FYI, it was setting the whole content of the user entry again, including email and preferences etc. That is what has been replaced by [private data]

I'm pretty sure it's not meant to change user_name, it seems to be just a poorly-written query.

It might not be intended to, but it does. I have to wonder if you could get some race conditions if the user is being renamed while trying to log in here, so that this no-op update might actually change the name to something wrong. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Bryan Tong Minh

6:34 p.m.

Sorry for the previous empty mail, I clicked the wrong button. On Thu, Jun 26, 2008 at 8:21 PM, Simetrical <Simetrical+wikilist(a)gmail.com> wrote:

...

On Thu, Jun 26, 2008 at 2:03 PM, Bryan Tong Minh <bryan.tongminh(a)gmail.com> wrote:

FYI, it was setting the whole content of the user entry again, including email and preferences etc. That is what has been replaced by [private data]

It is. CentralAuthPlugin::updateUser (which is according to documentation called each login) always sets the local email to the global email.

...

On Thu, Jun 26, 2008 at 2:09 PM, Roan Kattouw <roan.kattouw(a)home.nl> wrote:

I'm pretty sure it's not meant to change user_name, it seems to be just a poorly-written query.

It's a todo on User::saveSettings: "@todo Only rarely do all these fields need to be set!" Bryan

Simetrical

6:43 p.m.

On Thu, Jun 26, 2008 at 2:34 PM, Bryan Tong Minh <bryan.tongminh(a)gmail.com> wrote:

...

It is. CentralAuthPlugin::updateUser (which is according to documentation called each login) always sets the local email to the global email.

That seems unnecessary. Perhaps it could be fixed? Especially if it's causing locking problems (although I'm not sure what it's contending with for the lock).

...

It's a todo on User::saveSettings: "@todo Only rarely do all these fields need to be set!"

Okay, so can we ditch the setting user_name to $mName, at least? The only thing that should legitimately be saving changes to user_name is RenameUser, and that doesn't use User::saveSettings, it does a direct query. Anything saving changes to user_name is going to want to do a whole bunch of direct queries, anyway. The only problem is if someone, somewhere, in some broken extension, actually called setName() followed by saveSettings() and expected it to *work* (which the name of the method totally doesn't suggest, anyway).

Roan Kattouw

6:50 p.m.

Simetrical schreef:

...

Why don't we keep the 'current' settings around when they're load()ed and have saveSettings() check which settings changed (if any), and update only those? Roan Kattouw (Catrope)

Chad

6:51 p.m.

On Thu, Jun 26, 2008 at 2:43 PM, Simetrical <Simetrical+wikilist(a)gmail.com> wrote:

...

On Thu, Jun 26, 2008 at 2:34 PM, Bryan Tong Minh <bryan.tongminh(a)gmail.com> wrote:

It is. CentralAuthPlugin::updateUser (which is according to documentation called each login) always sets the local email to the global email.

That seems unnecessary. Perhaps it could be fixed? Especially if it's causing locking problems (although I'm not sure what it's contending with for the lock).

It's a todo on User::saveSettings: "@todo Only rarely do all these fields need to be set!"

What if User::saveSettings() accepted an array of column names/values to put into the update? If it's left null, it would save all settings, keeping backward compatibility. -Chad

Roan Kattouw

6:09 p.m.

Simetrical schreef:

...

On Thu, Jun 26, 2008 at 11:24 AM, Roan Kattouw <roan.kattouw(a)home.nl> wrote:

I'm 100% sure the API does no write queries to the user table, as there were no write queries in the API until I started writing them. This must be something in the initialization process that maybe updates the timestamp of last login/activity or something else. It could also be an extension.

...

Especially UPDATE user SET user_name . . . why should anything other than Special:RenameUser be touching user_name *ever*?

I'm pretty sure it's not meant to change user_name, it seems to be just a poorly-written query. Roan Kattouw (Catrope)

5797

days inactive

5799

days old

wikitech-l@lists.wikimedia.org

Manage subscription

10 comments

4 participants

tags (0)

participants (4)

Bryan Tong Minh
Chad
Roan Kattouw
Simetrical