I also had this kind of problem. My fault was opening database connections and not closing them properly, so
after a while the connection pool was full. The next time a page wanted to access the database, it stalled because
it was waiting for a free connection from the pool - so I thought it was cocoon that stalled and had to restart
the container.
In general, most times when cocoon stalls (and cpu usage does not go up to 100% so you're sure you're not in an
infinite loop) its because of some pool shortage. The database connection pool with 10 max. connections (default)
is the first thing to check.
These kind of errors are hard to find since it's the desired behaviour for a *working* application :-) So here's how
I found the error, hope it might help:
I created an additional sitemap entry with a really *simple* XSP page:
sitemap entry:
<map:match pattern="test">
<map:generate type="serverpages" src="test.xsp"/>
<map:serialize type="xml"/>
</map:match>
test.xsp:
<?xml version="1.0" encoding="iso-8859-1"?>
<xsp:page
xmlns:xsp="http://apache.org/xsp";>
<root>
</root>
</xsp:page>If cocoon had stalled it would not have rendered this page, but it rendered o.k. So I tried adding elements
from XSP namespaces I used (session, esql) and noticed that when I tried to execute an sql query, the page
did not render anymore. That got me on the right track to finally eliminate the error.
If you create a simple additional sitemap entry like that, does cocoon serve it or does it really "stall" ?
Joose Vettenranta wrote:
Hi,
I've had problems with freezing/stalling from time to time in very oddly places and times. Sometimes it's fop which hangs but sometimes it's just some sub sitemap like today. Restarting tomcat helps. Same stalling happened with tomcat 4.1.21 and cocoon 2.0.3...
If I have to access XSP-files so those are compiled many times, something might stall/freeze/jam after that.
I would like to know why it freezes (is the problem tomcat or cocoon?). Most likely no one is not able to say for sure, but I would like to know some tips or instructions how to track that problem, like when it stalls, then what?
And how to fix this annoying problem?
Setup:
Base system: Redhat 9
Apache 2.0.something acting as proxy. (this is not a problem, because direct access to tomcat is not working when something is stalled)
Tomcat 4.1.29 Cocoon 2.1.3 Java SDK = 1.4.2_02
Log file is sometimes registering calls but sometimes not. It just stalls somewhere. Memory is not short.
tomcat is run using following command line:
/usr/java/j2sdk1.4.2_02/bin/java-server-Xmx1536m-Xincgc- Djava.awt.headless=true-Djava.endorsed.dirs=/var/tomcat4.1.29/common/ endorsed-classpath/usr/java/j2sdk1.4.2_02/lib/tools.jar:/var/ tomcat4.1.29/bin/bootstrap.jar-Dcatalina.base=/var/tomcat4.1.29- Dcatalina.home=/var/tomcat4.1.29-Djava.io.tmpdir=/var/tomcat4.1.29/ temporg.apache.catalina.startup.Bootstrapstart
according to log files, there is lot's of free memery.
tomcat-config:
<Engine name="Standalone" defaultHost="localhost" debug="8">
<Host name="localhost" debug="8" appBase="/var/tomcat4.1.29/webapps/"
unpackWARs="true" autoDeploy="true">
<Logger className="org.apache.catalina.logger.FileLogger"
directory="logs" prefix="localhost_log." suffix=".txt"
timestamp="true"/>
<Context path="" docBase="cocoon" debug="8" />
</Host>
in sitemap.xmap (top-level) I have:
<map:transformer logger="sitemap.transformer.xslt" name="xslt" pool-grow="2" pool-max="256" pool-min="8" src="org.apache.cocoon.transformation.TraxTransformer">
<use-request-parameters>false</use-request-parameters>
<use-session-parameters>false</use-session-parameters>
<use-cookie-parameters>false</use-cookie-parameters>
<xslt-processor-role>xalan</xslt-processor-role>
</map:transformer>
<map:serializer logger="sitemap.serializer.fo2pdf" mime-type="application/pdf" name="fo2pdf" pool-grow="4" pool-max="128" pool-min="4" src="org.apache.cocoon.serialization.FOPSerializer">
cocoon.xconf has this memory configuration:
<store-janitor logger="core.store.janitor">
<!-- How much free memory shall be available in the jvm -->
<parameter name="freememory" value="5000000"/>
<!-- Indicates the limit of the jvm memory consumption. The default max
heapsize for Sun's JVM is (almost) 64Mb -->
<parameter name="heapsize" value="146000000"/>
<!-- How often shall the cleanup thread check memory -->
<parameter name="cleanupthreadinterval" value="10"/>
<!-- Experimental adaptive algorithm for cleanup interval
<parameter name="adaptivethreadinterval" value="true"/>
-->
<!-- Indicates the thread priority of the cleanup thread -->
<parameter name="threadpriority" value="5"/>
<!-- How much percent of the elements of each registered Store
shall be removed when low on memory. Default 10% -->
<parameter name="percent_to_free" value="10"/>
<!-- Invoke the garbage collector when low memory is reached -->
<parameter name="invokegc" value="false"/>
</store-janitor>
in logkit.xconf I have setup so debug level is DEBUG
- Joose
-- "Always remember that you are unique, just like everyone else!" * http://iki.fi/joose/ * [EMAIL PROTECTED] * +358 44 561 0270 *
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
