[
https://issues.apache.org/jira/browse/VELOCITY-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Martin updated VELOCITY-203:
-----------------------------------
Attachment: Generator.java.patch
This patch to Generator.java, when applied, makes the test ant xml file succeed.
The way it works is that it stores all the writers in a subclass of
org.apache.commons.collections.map.LRUMap limited to 100 entries that closes
files as they age out of the cache. At the same time, it does remember each
pathname written to in case that pathname needs to be written to again - if a
pathname is written to a second time, it opens the file in append mode.
Note that other components of velocity already use
org.apache.commons.collections.map.LRUMap so this shouldn't introduce any new
dependencies.
> No upper limit on cached file handles causes random ResourceLoader exceptions
> -----------------------------------------------------------------------------
>
> Key: VELOCITY-203
> URL: https://issues.apache.org/jira/browse/VELOCITY-203
> Project: Velocity
> Issue Type: Bug
> Components: Texen
> Affects Versions: 1.0-Release
> Environment: Operating System: other
> Platform: Other
> Reporter: Ian Ragsdale
> Assigned To: Velocity-Dev List
> Attachments: breaktexen.xml, Generator.java.patch
>
>
> The Generator class caches filehandles while generating files. There is no
> upper limit on the number of filehandles it will cache, so when generating
> many
> files with the same generator, it eventually hits the per-process limits on
> the
> number of open files. This then causes failures in the resource loader
> because
> it cannot open any more files. I've seen this problem on OS X and Linux, but
> it
> should be a pretty universal problem.
> You can work around this problem by increasing the number of filehandles
> available to the ant task, but that isn't always easy to do when running it
> as a
> subtask from an IDE, and it should be fairly simple to implement a basic LRU
> scheme.
> An alternative fix would be to more accurately report the error - the current
> implementation just throws a ResourceNotFound exception, making it very hard
> to
> track down the root cause of the error.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
