Closed Bug 1025480 Opened 11 years ago Closed 11 years ago

TemplateExecutionError at document offset 7136 in macro jsapixref ([u'JS_SetGCZeal'])

Categories

(developer.mozilla.org Graveyard :: General, defect)

Product:
developer.mozilla.org Graveyard
Component:
General
Platform:
All
Other
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: asqueella, Unassigned)

Details

(Whiteboard: [specification][type:bug])

What did you do? ================ 1. edited https://developer.mozilla.org/en-US/docs/Components.utils What happened? ============== There are scripting messages on this page: TemplateExecutionError at document offset 7136 in macro jsapixref ([u'JS_SetGCZeal']) ( edit ): Problem executing template jsapixref: 114 | <tr> 115 | <td><a href="/en/Components.utils.setGCZeal" title="en/Components.utils.setGCZeal"><code>setGCZeal()</code></a></td> 116 | <td>Sets the level of garbage collection level for full garbage collection. See {{ jsapixref("JS_SetGCZeal") }} for details; this method calls through to that with the specified value as the <code>zeal</code> value. {{ gecko_minversion_inline("10.0") }}</td> -------------------------------------------------------------------------------------------^ 117 | </tr> 118 | </tbody> TypeError: Cannot call method 'execute' of null at /data/www/developer.mozilla.org/kuma/kumascript/lib/kumascript/api.js:320:26 at /data/www/developer.mozilla.org/kuma/kumascript/lib/kumascript/loaders.js:187:25 at Object.callback (/data/www/developer.mozilla.org/kuma/kumascript/lib/kumascript/caching.js:439:13) at Client.memcached.delegateCallback (/data/www/developer.mozilla.org/kuma/kumascript/node_modules/memcached/lib/memcached.js:679:12) at Client.rawDataReceived (/data/www/developer.mozilla.org/kuma/kumascript/node_modules/memcached/lib/memcached.js:738:22) at Client.BufferBuffer (/data/www/developer.mozilla.org/kuma/kumascript/node_modules/memcached/lib/memcached.js:662:12) at Socket.bowlofcurry (/data/www/developer.mozilla.org/kuma/kumascript/node_modules/memcached/lib/utils.js:126:15) at Socket.EventEmitter.emit (events.js:95:17) at Socket.<anonymous> (_stream_readable.js:746:14) at Socket.EventEmitter.emit (events.js:92:17) TemplateExecutionError at document offset 7696 in macro interface ([u'nsIXPCComponents_utils_Sandbox']) ( edit ): Problem executing template interface: 129 | <tr> 130 | <td><code><a href="/en/Components.utils.Sandbox" title="en/Components.utils.Sandbox">Sandbox</a></code></td> 131 | <td>{{ interface("nsIXPCComponents_utils_Sandbox") }}</td> ---------------^ 132 | <td>Creates sandbox objects for use with <code>evalInSandbox()</code>.</td> 133 | </tr> TypeError: Cannot call method 'execute' of null at /data/www/developer.mozilla.org/kuma/kumascript/lib/kumascript/api.js:320:26 at /data/www/developer.mozilla.org/kuma/kumascript/lib/kumascript/loaders.js:187:25 at Object.callback (/data/www/developer.mozilla.org/kuma/kumascript/lib/kumascript/caching.js:439:13) at Client.memcached.delegateCallback (/data/www/developer.mozilla.org/kuma/kumascript/node_modules/memcached/lib/memcached.js:679:12) at Client.rawDataReceived (/data/www/developer.mozilla.org/kuma/kumascript/node_modules/memcached/lib/memcached.js:738:22) at Client.BufferBuffer (/data/www/developer.mozilla.org/kuma/kumascript/node_modules/memcached/lib/memcached.js:662:12) at Socket.bowlofcurry (/data/www/developer.mozilla.org/kuma/kumascript/node_modules/memcached/lib/utils.js:126:15) at Socket.EventEmitter.emit (events.js:95:17) at Socket.<anonymous> (_stream_readable.js:746:14) at Socket.EventEmitter.emit (events.js:92:17) What should have happened? ========================== no error Is there anything else we should know? ====================================== see also bug 957703
This is a transient error. I pressed shift-reload a few hours later and it went away. I'm cc/ Les to see if he can get some information from the info. If not, we should close this specific issue as it solved (though the real problem is still there).
There was actually a typo in the macro code. Note the stray "u" before the string in the macro invocation. This is fixed, at any rate.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
> There was actually a typo in the macro code. Note the stray "u" before the string There were no changes to the macro code since 2013: https://developer.mozilla.org/en-US/docs/Template:jsapixref$history and the 'stray' "u" usually indicates a Unicode string <http://stackoverflow.com/questions/2464959/whats-the-u-prefix-in-a-python-string> This was a temporary problem, which fixed itself. Judging from <https://github.com/mozilla/kumascript/blob/master/lib/kumascript/loaders.js#L187> kumascript engine makes a few attempts to load the template after which it gives up and displays this error message. I think it would be appropriate 1) to figure out what kind of failures cause this error 2) to ensure the service involved is monitored via something like nagios. 3) to log a more understandable error message FWIW my experience of editing with kuma regularly involves site problems (template errors, general slowness and instability), which is why I would like this bug to get more attention from the dev team. See also https://groups.google.com/d/topic/mozilla.mdn.drivers/mavYd2W_L_A/discussion for the list of other errors that seem to be ignored, sadly.
I'm feedbacking :groovecoder and :hoosteeno so that that can follow-up (answers or actions) on the three proposals.
Flags: needinfo?(lcrouch)
Flags: needinfo?(hoosteeno)
(In reply to Nickolay_Ponomarev from comment #3) > > There was actually a typo in the macro code. Note the stray "u" before the string > > There were no changes to the macro code since 2013: > https://developer.mozilla.org/en-US/docs/Template:jsapixref$history and the > 'stray' "u" usually indicates a Unicode string > <http://stackoverflow.com/questions/2464959/whats-the-u-prefix-in-a-python- > string> Except the "u" was being used in KumaScript, which is executed as JavaScript, not as Python.
> 1) to figure out what kind of failures cause this error Not sure, but I think this line of the error suggests there was a memcache service failure when kumascript tired to access it: > at Client.memcached.delegateCallback (/data/www/developer.mozilla.org/kuma/kumascript/node_modules/memcached/lib/memcached.js:679:12) > 2) to ensure the service involved is monitored via something like nagios. The kumascript service is monitored by nagios, if I recall. Memcached might be, also, I'd hope. Problem is, this was probably a transient error that resolved itself before any monitoring could catch it. Kumascript itself was not entirely down, so no alarm would have gone off. > 3) to log a more understandable error message This looks like an unexpected error from deep inside the core of Kumascript. As things like this fail, we can wrap them with better messages. But, I think this is the first time for this particular exact failure.
Les, thanks for your comments! As far as I remember, this didn't go away for a few (5-30 mins) minutes with shift-refresh before I filed a bug, but if you say this would've been picked up by nagios if it lasted long enough, then I'm probably misremembering (although it would be nice to get a confirmation..) I guess the only thing that could be improved wrt monitoring would be logging such errors to Sentry (bug 1020487), then. The error message could then say that the failure was automatically logged. (Eric, although the error happens in kumascript, the error is logged from Python code: https://github.com/mozilla/kuma/blob/master/apps/wiki/templates/wiki/includes/kumascript_errors.html#L15 )
(In reply to Nickolay_Ponomarev from comment #7) > Les, thanks for your comments! As far as I remember, this didn't go away for > a few (5-30 mins) minutes with shift-refresh before I filed a bug, but if > you say this would've been picked up by nagios if it lasted long enough, > then I'm probably misremembering (although it would be nice to get a > confirmation..) I'm assuming it was a) a memcached service failure and b) memcached is monitored by nagios. Honestly, I'm not sure of either of those assumptions. Though, it wasn't a full kumascript failure, because that error message was produced by kumascript itself. > I guess the only thing that could be improved wrt monitoring would be > logging such errors to Sentry (bug 1020487), then. The error message could > then say that the failure was automatically logged. Yes, I think getting error messages into sentry is one of the most important next steps for kumascript.
This bug happened while MDN was experiencing a site-wide outage (see bug 1032046). memcache is monitored by New Relic and it did catch the drop in requests. I don't know if memcache itself failed, or if just the connection failed. I would go with Les' assumption that a memcache connection failure caused the original bug.
We now have New Relic monitoring on the memcache servers. [1] :cyliang - do we have nagios monitoring & alerting on these too? [1] https://rpm.newrelic.com/accounts/263620/plugins?type=2854
Flags: needinfo?(lcrouch) → needinfo?(cliang)
It looks like there was just Nagios basic monitoring (which is common across all servers). I've added a memcached check, which looks like it 1) verifies that memcache is running and 2) warns if there are more than 4000 connections (going into critical at 4500 connections).
Flags: needinfo?(cliang)
This is well in hand with the folks working on it. Please needinfo me again if there are product questions to discuss.
Flags: needinfo?(hoosteeno)
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.