cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fabrizio Sitzia" <>
Subject SQLTransformer makes Cocoon hang under high load
Date Thu, 30 Jun 2005 17:04:40 GMT

I'm developing a dynamic Cocoon webapp that performs a lot of (nested) queries
using the SQLTransformer.

The SQLTransformer performs SELECT operations only, and it is configured to
use a JDBC database connection pool that is managed by Cocoon itself.
Excerpt from cocoon.xconf:

    <jdbc logger="core.datasources.db" name="db">
      <pool-controller min="5" max="50"/>

At some point, I decided to stress-test the webapp using the 'ab'-tool (Apache
benchmark) to simulate a large number of concurrent requests.

When the number of concurrent requests is heading towards the 'max' number of
pooled database connections, the following occurs:

- The 'ab' benchmark is aborted with a timeout error.

- Using a database monitoring tool, you will notice that the 'max' number of
pooled database connections have been left open.

- Cocoon 'hangs' indefinitely!
Any further requests to the webapp will timeout, and nothing gets written to
the logs (access.log, error.log...)
There are no warnings, nor any error messages in the logs that would indicate
why the hang occured in the first place. Up to the hang, everything appears to
run normally!

That's scary!

Currently, I work around the problem with a big axe! That is, by limiting the
number of socket listener threads of the servlet container, and by defining a
rather oversized pool of database connections.
Excerpt from Jetty's main.xml configuration file:

  <Call name="addListener">
      <New class="org.mortbay.http.SocketListener">
        <Set name="MinThreads">8</Set>
        <Set name="MaxThreads">16</Set>

My best guess is that the SQLTransformer will wait indefinitely (causing
Cocoon to hang) if it fails to get a database connection from the pool.

The SQLTransformer further appears to require more than one database
connection (...which seems to be related to the depth of query nesting levels,
but that's a far-fetched guess!)

Has someone out there experienced similar problems, or have a more
enlightening  explanation to what is going on?

As my fix is based on a lot of guesswork, I would welcome a more robust solution.

Best regards,

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message