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)

x86
macOS
defect
Not set
blocker

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.
Depends on: 770271
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.
This specificproblem disappeared on Monday, it might indeed has been the leap-second problem.
This is still happening, see bug 770271
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.
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.
There is an improvement. It is again possible to use Kuma decently. I will confirm later, but at first sight, it is much better.
So I confirm it is much much better. But there still are some transient ETimedOut, but far less.
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.
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
I confirm that I don't experience the original problem since the launch at least.
Version: Kuma → unspecified
Component: Website → Landing pages
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.