velocity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Martin (JIRA)" <>
Subject [jira] Updated: (VELOCITY-203) No upper limit on cached file handles causes random ResourceLoader exceptions
Date Sat, 07 Apr 2007 11:42:32 GMT


Daniel Martin updated VELOCITY-203:


This patch to, when applied, makes the test ant xml file succeed.

The way it works is that it stores all the writers in a subclass of
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
so this shouldn't introduce any new dependencies.

> No upper limit on cached file handles causes random ResourceLoader exceptions
> -----------------------------------------------------------------------------
>                 Key: VELOCITY-203
>                 URL:
>             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,
> 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:
For additional commands, e-mail:

View raw message