Bugzilla – Bug 543
Request Timeout when accessing param in a Skin
Last modified: 2007-11-26 16:43:49
You need to log in before you can comment on or make changes to this bug.
I got bitten by a bug in Helma 1.6.0 that i currently don't fully understand but i am able to reproduce it within a demo application. The Bug is reproduceable with Helma 1.6.0 and the snapshot from today but NOT 1.5.3. JDK Version and OS don't seem to have an affect. The Bug occurs in a Skin when accessing "param" but only on HopObjects that were added a few moments before. function render(type){ var param = { type: type }; return this.renderSkinAsString("test", param); } test.skin: _<% param.type %>_ It never returns from "renderSkinAsString" and consumes a lot of CPU time. Although my knowledge of the Helma internals is very limited i think this is only the result of the bug not the problem itself. I come to this conclusion because if i restart the application everything is fine. Adding a new "DebugElement" to the "pool" is okay but as soon as i access this new object on the next page the bug occurs. "Flush" in the manage app or restarting helma helps and everything works fine again as long as you don't add a new object and access it's render() method again. I am not sure if it helps or is related at all but i got a few stacktraces from the running helma thread that renders this page and never comes back. Please remind that i already have reproduced it with FreeBSD 6.2 running diablo-1.5.0_07-b01 and Debian 4.0 running 1.6.0_01-b06. Name: TX-debug State: RUNNABLE Total blocked: 860 Total waited: 4 Stack trace: java.lang.String.toLowerCase(String.java:2242) java.lang.String.toLowerCase(String.java:2296) helma.framework.core.TypeManager.getPrototype(TypeManager.java:277) helma.framework.core.Application.getPrototype(Application.java:909) helma.framework.core.Skin$RenderContext.resolveHandler(Skin.java:1104) helma.framework.core.Skin$RenderContext.access$400(Skin.java:1060) helma.framework.core.Skin$Macro.invokeAsMacro(Skin.java:650) helma.framework.core.Skin$Macro.render(Skin.java:752) helma.framework.core.Skin.render(Skin.java:276) helma.framework.core.Skin.renderAsString(Skin.java:231) helma.scripting.rhino.HopObject.jsFunction_renderSkinAsString(HopObject.java:274) sun.reflect.GeneratedMethodAccessor59.invoke(Unknown Source) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:585) org.mozilla.javascript.MemberBox.invoke(MemberBox.java:155) org.mozilla.javascript.FunctionObject.call(FunctionObject.java:474) org.mozilla.javascript.optimizer.OptRuntime.call2(OptRuntime.java:76) org.mozilla.javascript.gen.c60._c1(/usr/home/decke/.workspace/helma/../c3kcom/debug/DebugElement/functions.js:7) org.mozilla.javascript.gen.c60.call(/usr/home/decke/.workspace/helma/../c3kcom/debug/DebugElement/functions.js) org.mozilla.javascript.optimizer.OptRuntime.call1(OptRuntime.java:66) org.mozilla.javascript.gen.c59._c1(/usr/home/decke/.workspace/helma/../c3kcom/debug/Debug/main.hac:7) org.mozilla.javascript.gen.c59.call(/usr/home/decke/.workspace/helma/../c3kcom/debug/Debug/main.hac) org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:393) org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2834) org.mozilla.javascript.gen.c59.call(/usr/home/decke/.workspace/helma/../c3kcom/debug/Debug/main.hac) org.mozilla.javascript.Context.call(Context.java:538) helma.scripting.rhino.RhinoEngine.invoke(RhinoEngine.java:296) helma.framework.core.RequestEvaluator.run(RequestEvaluator.java:389) java.lang.Thread.run(Thread.java:595) I have put a stripped down demo application that is able to reproduce the bug here: http://home.bluelife.at/bugs/ - read the readme.txt for details.
Created an attachment (id=62) [details] Demo app that is able to reproduce the bug
As a workaround it helps if you invalidate the parent (the DebugPool) after you have added the new object.
Thanks for the report and the nice demo app. The problem seems to be caused by a loop in the parent lookup in the macro handler code. But I still have to investigate why it generates the strange timeout message.
we just also got bitten nastily by this very same bug. thanks to your bug-report, we could at least find a quick workaround for it (i.e. define a proper _parent-setting in type.properties).
btw: the reason why we didn't have a proper _parent-setting was, that currently it is not possible to specify the named collection of a mountpoint as a parent, since Helma does not support this syntax: _parent = root.locations.allLocations maybe this can also be fixed along with fixing this bug.
(Mit Bezug zu comment 5) > btw: the reason why we didn't have a proper _parent-setting was, that currently > it is not possible to specify the named collection of a mountpoint as a parent, > since Helma does not support this syntax: > > _parent = root.locations.allLocations > > maybe this can also be fixed along with fixing this bug. > defining 3-element _parent definitions should be working now (see bug #563)
Marking as FIXED. With better _parent support and some safety belts added, this shouldn't happen anymore.