Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: pass (athena.apache.org: domain of
 insomniacpenguin@googlemail.com designates 209.85.142.191 as permitted
 sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=iaeswyLRJs6iAMkBUQuwY8mPH3TcEBj045vvt0v0G/uB+2npL/iiyFvQeTINgLk5muGoPOtLxIzvEEQJvfZxlXDP8eISiW0K01kdY65pF2Y6e5gmMPH6z6PKEQRZ7meoOSmTJEppZiddVQCzkoQtfgVeWJqFWUk2PWkIJRIX30E=
Message-ID: <efe2a0400805071022l15b3e718v11cf6753b2cc1569@mail.gmail.com>
Date: Wed, 7 May 2008 18:22:46 +0100
From: "Andy Stevens" <insomniacpenguin@googlemail.com>
To: users@cocoon.apache.org
Subject: Too many open files (was PDF Image Caching Problem)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

2008/5/5 Lehtonen, Mika <mika@digikartta.net>:
>  Actually there might be another problem (or bug) lying around if you
> produce htmls' with 'noncaching' option. Cocoon seems to be leaving files
> open when using html-serializer with noncaching option in your pipeline. And
> eventually your application can crash because you exceed the maximum open
> files that your OS tolerates. (Cocoon 2.1.11 / Centos 4.6)

Really?  Aha...

It's not the cocoon.xconf that's left open is it?  And could this
affect earlier versions too?  I mailed the dev list about a week ago
(subject "Excessive file handles on cocoon.xconf", see
http://www.nabble.com/Excessive-file-handles-on-cocoon.xconf-tp16973172p17000464.html)
because we were encountering "Too many open files" errors after
migrating a 2.1.7 app from Websphere 5.0 on Windows to 6.0 on Linux.
I'm wondering if this could be the reason.

Do the files get closed eventually? We were getting these errors with
the limit set to 1024, but after a few minutes things would start
working again for a while.  Also, after increasing the limit to 8000
we haven't seen the error since.  I assume this is because it's now
high enough for the responsible component(s) to get destroyed, garbage
collected, and basically cleaned up properly before things get that
bad.


Andy
-- 
http://pseudoq.sourceforge.net/  Open source java Sudoku application

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org