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]

Reply via email to