[ 
https://issues.apache.org/jira/browse/FOP-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557259#comment-13557259
 ] 

Chris Bowditch edited comment on FOP-2189 at 1/18/13 3:08 PM:
--------------------------------------------------------------

The FontFileReader class has been refactored in trunk. Both the constructors 
listed above have been removed in favour of the init method thats been renamed 
into the constructor. That doesnt contain an explicit call to close, but the 
classes calling FontFileReader such as TTFFontLoader now call close in their 
finally block, e.g.

        InputStream in = resourceResolver.getResource(this.fontFileURI);
        try {
            TTFFile ttf = new TTFFile(useKerning, useAdvanced);
            FontFileReader reader = new FontFileReader(in);
            boolean supported = ttf.readFont(reader, ttcFontName);
            if (!supported) {
                throw new IOException("TrueType font is not supported: " + 
fontFileURI);
            }
            buildFont(ttf, ttcFontName);
            loaded = true;
        } finally {
            IOUtils.closeQuietly(in);
        }

Therefore I believe this issue is resolved in trunk and this bug can be closed. 
You will need to upgrade to trunk to your resolve the problem in your 
environment.
                
      was (Author: cbowditch):
    The FontFileReader class has been refactored in trunk. Both the 
constructors listed above have been removed in favour of the init method that 
beens renamed into the constructor. That doesnt contain an explicit call to 
close, but the classes calling FontFileReader such as TTFFontLoader now call 
close in their finally block, e.g.

        InputStream in = resourceResolver.getResource(this.fontFileURI);
        try {
            TTFFile ttf = new TTFFile(useKerning, useAdvanced);
            FontFileReader reader = new FontFileReader(in);
            boolean supported = ttf.readFont(reader, ttcFontName);
            if (!supported) {
                throw new IOException("TrueType font is not supported: " + 
fontFileURI);
            }
            buildFont(ttf, ttcFontName);
            loaded = true;
        } finally {
            IOUtils.closeQuietly(in);
        }

Therefore I believe this issue is resolved in trunk and this bug can be closed. 
You will need to upgrade to trunk to your resolve the problem in your 
environment.
                  
> Apache FOP 1.0 Multithreading Problems - Too many open files err24
> ------------------------------------------------------------------
>
>                 Key: FOP-2189
>                 URL: https://issues.apache.org/jira/browse/FOP-2189
>             Project: Fop
>          Issue Type: Bug
>          Components: pdf
>    Affects Versions: 1.0
>         Environment: HP Unix 
>            Reporter: Joey Ezekiel
>              Labels: Exception, Font", IOException, PDF, error
>
> We use Apache FOP to convert a whole lot of XML's to AFP's and PDF's. Our 
> current load would be around 25k files per run on a HP-UX system. We have 12 
> threads in total that are used to initialize and trigger the FOP conversion 
> in a producer-consumer fashion. Recently there have been multiple failures 
> during conversion and when looked up, we've received generic FOP errors like:
> **ERROR,2460364,FOToPDF_Thread_11,FOP Exception, something.pdf,Failed to 
> resolve font with embed-url './Fonts/arial.ttf'**
> or its an error failing to load the font metrics file although the files are 
> intact with the right permissions. Many other PDF's are generated so this 
> can't be the problem.
> We also wind up with:
> **java.io.FileNotFoundException: /PDF/20130111130002/something.pdf (Too many 
> open files (errno:24))**
> judging by the logs and volume being processed, this looks like an FOP 
> problem. I've read that FOP has had this issue in the past with the font 
> files. There have been instances where Apache has opened each font file 
> multiple times and not closed the handles resulting in a large number of open 
> files. This was supposed to be fixed, but if it still persists, what would be 
> a good and quick solution to this?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to