On 08.10.2008 17:20, Thorsten Mauch wrote:
Hi All
I have a really weird problem with cocoon 2.1.11. My Application becomes
very slow under a load, even if it now relay heavy. A page request take
up to one Minute.
The strange point is that in another application I use exactly the same
java code and it works well.
All my request a past to a flow script and handled there. The time spend
in the flow (10 ms) is very small can not cause the problem.
With visualvm I figure out that a lot threads are blocked:
http-8080-34" daemon prio=10 tid=0x081a0800 nid=0x45aa waiting for
monitor entry [0x9dc4c000..0x9dc4cdc0]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.setupContext(FOM_JavaScriptInterpreter.java:571)
- waiting to lock <0xa6089138> (a java.util.HashMap)
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.callFunction(FOM_JavaScriptInterpreter.java:718)
- locked <0xa7dea538> (a
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter$ThreadScope)
The bad point is that I have absolutely no idea what the root cause of
this is. Any help what I could check is really appreciated
This does not look like an issue with XSLT processors or other pooled
components since it's simply an area of code that's blocked. I have no
idea if setupContext() is such a heavy operation. From your other mail I
saw you tried disabling reloading of the scripts without success. Did
you fail disabling it or did it just have no effect? Do you use certain
features in the scripts which you don't use in other applications? IIRC
importPackage was once causing problems. Is it possible to figure out
what in setupContext() or compileScript() (both locking on
compiledScript) costs so much time?
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]