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
Bryan Tong Minh schreef:
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.
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)
On Thu, Jun 26, 2008 at 11:24 AM, Roan Kattouw roan.kattouw@home.nl wrote:
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.
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*?
On Thu, Jun 26, 2008 at 7:55 PM, Simetrical Simetrical+wikilist@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
On Thu, Jun 26, 2008 at 2:03 PM, Bryan Tong Minh bryan.tongminh@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@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 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.
On Thu, Jun 26, 2008 at 8:21 PM, Simetrical Simetrical+wikilist@gmail.com wrote:
On Thu, Jun 26, 2008 at 2:03 PM, Bryan Tong Minh bryan.tongminh@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@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 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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Sorry for the previous empty mail, I clicked the wrong button.
On Thu, Jun 26, 2008 at 8:21 PM, Simetrical Simetrical+wikilist@gmail.com wrote:
On Thu, Jun 26, 2008 at 2:03 PM, Bryan Tong Minh bryan.tongminh@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.
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@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 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.
It's a todo on User::saveSettings: "@todo Only rarely do all these fields need to be set!"
Bryan
On Thu, Jun 26, 2008 at 2:34 PM, Bryan Tong Minh bryan.tongminh@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).
Simetrical schreef:
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).
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)
On Thu, Jun 26, 2008 at 2:43 PM, Simetrical Simetrical+wikilist@gmail.com wrote:
On Thu, Jun 26, 2008 at 2:34 PM, Bryan Tong Minh bryan.tongminh@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).
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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
Simetrical schreef:
On Thu, Jun 26, 2008 at 11:24 AM, Roan Kattouw roan.kattouw@home.nl wrote:
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.
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?
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)
wikitech-l@lists.wikimedia.org