Bug 107939 - XSL files recursively opened without ever being closed
Summary: XSL files recursively opened without ever being closed
Alias: None
Product: Red Hat Web Application Framework
Classification: Retired
Component: other (Show other bugs)
(Show other bugs)
Version: 6.0
Hardware: All Linux
Target Milestone: ---
Assignee: ccm-bugs-list
QA Contact: Jon Orris
Depends On:
Blocks: 100952
TreeView+ depends on / blocked
Reported: 2003-10-24 19:06 UTC by Nuno Santos
Modified: 2013-09-12 22:08 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-12-10 16:44:49 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Nuno Santos 2003-10-24 19:06:44 UTC
This was reported by a client (Azimuth), I haven't reproduced it.

On 6.0, after running for a while, they're getting exceptions about the system
having too many files open. 

They've tracked it down to the importRecurseHelper method in
com.arsdigita.kernel.Stylesheet, which opens css files recursively, without ever
closing them. And they seem to have fixed it by putting a try-catch block and a
"finally { bufRead.close();}" in the method.

Dan suggested this could be a previously undetected interaction with the number
of files that Lucene opens for each search.

Comment 1 Daniel Berrange 2003-10-28 09:28:18 UTC
Can you post details of what the client has their OS file handle limit set to.
For RHEL, this is the output of 'cat /proc/sys/fs/file-nr ' and the
'/etc/security/limits.conf' file.

The way search can show problems is as follows:

 * Consider system file handle limit is 1024
 * Each lucene search query requires 200 handles
 * 5 users perform a search at the same time, causing 1000 handles to be opened
 * Another page triggers loading of a new XSL stylesheet, containing > 24 imports.

You'll now get a out of file handle message in the stylesheet code, even though
the problem is really with lucene.

We've had this occurr quite frequently on our PG installs & now allocate each
app server 8192 file handles per process (ie the limits.conf file) and a system
wide limit of 32678. 

As well as in XSL loading code, the error is also typically triggered in the
class loaders and JSP compilation steps, both of which open numerous files.

Comment 2 Daniel Berrange 2003-10-28 09:28:55 UTC
From the comments I assume this was meant to "XSL" rather than "CSS"

Comment 3 Archit Shah 2003-11-04 19:43:10 UTC
fixed on 5.2 (37686), 6.0 (37685), and dev (37685). Also putting note
in documentation about adjusting limit for max open files.

Comment 4 Richard Li 2003-11-04 20:01:39 UTC
adding to cms deployment guide @37687 -- should move to waf deployment
guide when we have one of those.

Comment 5 Nuno Santos 2003-11-06 15:48:13 UTC
Just for the sake of completness, here are the file limits on the
server that was seeing the problem:

cat /proc/sys/fs/file-nr
6084    3529    419430

/etc/security/limits.conf is empty (only commented lines), so
everything is on the default values.

Comment 6 Daniel Berrange 2003-11-06 15:53:03 UTC
FYI, we add the following to the limits.conf for servers running Lucene

servlet         soft    nofile  8192
servlet         hard    nofile  8192

The RHEL default is 1024, we used to up it to 4096, but occassionally
still had problems. Upping it again to 8192 seems to be high enough.

Note You need to log in before you can comment on or make changes to this bug.