Hi,
I've just filed this issue against Excalibur:
https://issues.apache.org/jira/browse/FORTRESS-22
ResourceSource.getInfos() leaves URLConnection open, resulting in
'too may open files' condition
This affected us on a busy live system serving dojo files from the jar
in the ajax block; it's really dependent on how often GC kicks in, how
busy your server is (serving ajax-using pages), and how many descriptors
you've got per-process. It doesn't matter if the pipeline is cached or
uncached, the validity checking is enough to trigger the 'leak'.
A configuration 'glitch' meant we had only 1024 file-descriptors
available, which meant we hit this bug earlier than we might otherwise
have. A work-around (other than to increase the number of
file-descriptors and keep your fingers crossed) is to pick up files
directly from where they are automatically de-archived:
<map:match pattern="resources/*/**">
<map:select type="resource-exists">
<map:when test="{0}">
<map:read src="{0}">
<map:parameter name="byte-ranges"
value="false"/>
</map:read>
</map:when>
<!-- test to see if resource has already been
unarchived (saves file-descriptors); tomcat specific -->
<map:when
test="{system-property:catalina.base}/work/contexts/localhost/_/loader/org/apache/cocoon/{1}/resources/{2}">
<map:read
src="{system-property:catalina.base}/work/contexts/localhost/_/loader/org/apache/cocoon/{1}/resources/{2}">
<map:parameter name="byte-ranges"
value="false"/>
</map:read>
</map:when>
<map:otherwise>
<!-- read resource from classpath -->
<map:read
src="resource://org/apache/cocoon/{1}/resources/{2}">
<map:parameter name="byte-ranges"
value="false"/>
</map:read>
</map:otherwise>
</map:select>
</map:match>
That is, if possible, the files are picked up from the work directory,
relative to catalina.base, rather than the jar. This will have to be
adapted for other containers, unless there's some other way to do it (I
don't think there's a context input-module so I can get at
work-directory parameter?).
Hope this is useful to someone else!
Ellis.
