Closed
Bug 769990
Opened 12 years ago
Closed 12 years ago
Since Saturday, almost permanent Kumascript service timed out
Categories
(developer.mozilla.org Graveyard :: Wiki pages, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: teoli, Unassigned)
References
Details
There are scripting messages on this page: TimeoutError 1 Request to Kumascript service timed out This started on Saturday. At Midnight PT (where I'm likely to be the only editor being Sunday morning in Europe), I got it all the time.
Comment 1•12 years ago
|
||
This seems likely to be the leap-second bug we've experienced with a lot of things, especially MySQL and Java... we don't have many Node.js apps, so it's hard to say with any certainty that this would have been relevant. The timing seems roughly correct, though, so I'd definitely point the finger there first. The fix for most things (MySQL/Java, at least) was to simply re-set the date, which we did on all our servers. That may not have been enough for Node.js for some reason. I have restarted Kumascript (and Apache for good measure), and developer-new.mozilla.org seems to be responding much better now. Not closing this in case someone from the MDN team would like to investigate more thoroughly.
Reporter | ||
Comment 2•12 years ago
|
||
This specificproblem disappeared on Monday, it might indeed has been the leap-second problem.
Comment 4•12 years ago
|
||
This is still happening, see bug 770271
Comment 5•12 years ago
|
||
A quick update for those watching this bug: The current theory is that this has little (possibly nothing) to do with Kumascript itself and is actually an issue in the main app. Since Kumascript calls Kuma to get data, any slowness in Kuma will necessarily be reflected in Kumascript.
Comment 6•12 years ago
|
||
Please let us know if this is improved now. We have disabled memcache in Kuma, and this seems to have improved Django response times considerably... which would in turn improve Kumascript's responsiveness.
Reporter | ||
Comment 7•12 years ago
|
||
There is an improvement. It is again possible to use Kuma decently. I will confirm later, but at first sight, it is much better.
Reporter | ||
Comment 8•12 years ago
|
||
So I confirm it is much much better. But there still are some transient ETimedOut, but far less.
Comment 9•12 years ago
|
||
I got this error because I made a typo in a template - so I had <% there but no corresponding %>. Any page using that template would load half a minute and notify me about a KumaScript timeout then.
Comment 10•12 years ago
|
||
It looks like the sporadic timeouts that we saw a month ago have gone away. I opened bug 785409 for the %> thing Wladimir mentioned.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 11•12 years ago
|
||
I confirm that I don't experience the original problem since the launch at least.
Assignee | ||
Updated•12 years ago
|
Version: Kuma → unspecified
Assignee | ||
Updated•12 years ago
|
Component: Website → Landing pages
Updated•4 years ago
|
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•