[00:03:16] gn8 folks [02:27:22] !log LocalisationUpdate completed (1.20wmf6) at Sat Jul 7 02:27:22 UTC 2012 [02:27:42] Logged the message, Master [10:41:13] I'm getting the "Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in." issue [16:10:51] !log reedy synchronized php-1.20wmf6/extensions/cldr/ 'remove bom' [16:11:01] Logged the message, Master [16:39:49] !log reedy synchronized docroot/bits/DolphinBrowser/js/ 'Remove BOM' [16:39:57] Logged the message, Master [18:00:49] Hi everyone. We're starting office hours for the experimental features team at the WMF now. Feel free to join in #wikimedia-office. [22:21:41] Hello! I once again come in here to ask you folks about maxlag. It's been consistently above 5 for about a week now (I use maxlag=5 in API queries, as people have recommended I use multiple times), which is bad because the API becomes nonfunctional. With the Toolserver's SQL also significantly lagged (over 14 hrs on the better server and 36 hours on the worse one), that leaves me with no reliable method to talk to the servers. Bots have been [22:21:42] offline or extremely slow for too long, and I can't see indication that this will resolve itself soon. What am I supposed to do? Not specify maxlag in API queries or increase it to a very high value? Pretend old data is accurate? Thanks. [22:31:19] I have also been affected by the maxlag problem, which has all but taken out several bots. [22:31:38] I don't see such maxlag in the toolserver [22:32:12] for the TS: [22:32:15] [6:32pm] Earwig: @replag [22:32:15] [6:32pm] tsbot: Earwig: s1-rr-a: 14h 3m 17s [+0.05 s/s]; s1-user: 1d 13h 30s [+0.04 s/s]; s3-rr-a: 1m 38s [+0.03 s/s]; s3-user: 1m 38s [+0.03 s/s] [22:32:38] @replag [22:32:39] Reedy: [s1] db32: 1s, db59: 9s [22:32:46] for the actual cluster, it fluctuates wildly; http://en.wikipedia.org/w/api.php?action=query&meta=siteinfo&siprop=dbrepllag [22:32:54] Here is an example: [22:32:56] [18:32] EarwigBot - Nathan2055: replag on enwiki_p is 50596 seconds. [22:32:56] ok, I think I was looking at s3 lag [22:32:58] [18:32] Helpmebot - Nathan2055: the maximum replication lag is 8 second(s). (Parts of the wiki may appear to be 8 second(s) out-of-date). [22:33:06] TS replag isn't usualy our fault [22:33:08] @maxlag [22:33:14] ... [22:33:20] I understand that, although DaB. has said it's because you guys are updating some sha1s [22:33:26] yeah [22:33:34] I'm willing to accept high TS replag if the actual API was more reliable [22:33:41] I'm just very frustrated because both are broken [22:33:49] The community wants it doing, so unfortunately, they'll just have to put up with it [22:33:53] The api isn't at fault [22:33:59] Wants what? [22:34:01] the... maxlag [22:34:10] have you considered that the same thing can be producing that state? [22:34:16] The sha1 hashes for revisions [22:34:22] Use a higher value of maxlag [22:34:27] lag < 10 seconds isn't an issue [22:34:30] use 20 or 30 [22:34:36] hm [22:34:40] problem solved [22:34:42] alright, will go for 25 [22:34:45] thanks for your input [23:28:22] [[Tech]]; 68.173.113.106; /* Native version of MediaWiki? */ ; https://meta.wikimedia.org/w/index.php?diff=3885534&oldid=3883258&rcid=3383079 [23:34:01] trolol? [23:35:26] Should totally rewrite it in c, 30min compile to check a change worked? Sounds a good idea :D [23:35:47] "Migration? My main idea was that the concept of a database change vector (used in Oracle software, probably integrated in MySQL) would be applied to the actual wiki pages so a database would be unnecessary except to map page names to oldid's. Theoretically, you could just look up pages by oldid." [23:37:14] [[Tech]]; MZMcBride; /* Native version of MediaWiki? */ +reply; https://meta.wikimedia.org/w/index.php?diff=3885555&oldid=3885534&rcid=3383098 [23:37:45] I don't really see how he thinks that making it with a build in database, assuming some sort of binary table implimentation is any better from a point of running it at scale than exisiting solutions with years of r&d and external work... as much as I hate oracle and mysql [23:39:54] [[Tech]]; Reedy; /* Native version of MediaWiki? */ moar; https://meta.wikimedia.org/w/index.php?diff=3885561&oldid=3885555&rcid=3383103 [23:42:22] MW does suffer from the age old problem - the easiest way to make databases fast is to not talk to them :)