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

Maurice Makaay edited comment on FOP-2525 at 1/28/17 5:55 PM:
--------------------------------------------------------------

Using the current Apache-FOP 2.1 in embedded mode, I was running into memory 
errors as well, due to memory leakage. Investigating where the memory went, my 
suspicion drifted towards complex scripts support and I ended up at this 
thread, where I found an acceptable (for my case) work-around: disable complex 
scripts.

The page that is linked to explains how to disable complex scripts in the FOP 
user agent object, but in 2.1 this works differently. You have to disable this 
through the FopFactoryBuilder.
For those who are running into the same issue, here's how I was able to fix it 
in my code:

{code:Java}
        FopFactoryBuilder builder = new FopFactoryBuilder(baseURI)
            .setConfiguration(cfg)
            .setComplexScriptFeatures(false); <-- this is where the magic goes
        fopFactory = builder.build();
{code}

After doing this, this FOP instance:

{code:Java}
        Fop fop = fopFactory.newFop(MimeConstants.MIME_PDF, userAgent, out);
{code}

no longer showed the memory leakage.
Before the change, my server went up to using 2GB+, eventually crashing.
After the change, it remained stable at about 100MB.
My Apache-FOP wrapping webserver did not crash every since.


was (Author: mmakaay):
Using the current Apache-FOP 2.1 in embedded mode, I was running into memory 
errors as well, due to memory leakage. Investigating where the memory went, my 
suspicion drifted towards complex scripts support and I ended up at this 
thread, where I found an acceptable (for my case) work-around: disable complex 
scripts.

The page that is linked to explains how to disable complex scripts in the FOP 
user agent object, but in 2.1 this works differently. You have to disable this 
through the FopFactoryBuilder.
For those who are running into the same issue, here's how I was able to fix it 
in my code:

            FopFactoryBuilder builder = new FopFactoryBuilder(baseURI)
                    .setConfiguration(cfg)
                    .setComplexScriptFeatures(false); <-- this is where the 
magic goes
            fopFactory = builder.build();

After doing this, this FOP instance:

        Fop fop = fopFactory.newFop(MimeConstants.MIME_PDF, userAgent, out);

no longer showed the memory leakage.
Before the change, my server went up to using 2GB+, eventually crashing.
After the change, it remained stable at about 100MB.
My Apache-FOP wrapping webserver did not crash every since.

> [PATCH] Excessive memory usage when using truetype collection (.ttc)
> --------------------------------------------------------------------
>
>                 Key: FOP-2525
>                 URL: https://issues.apache.org/jira/browse/FOP-2525
>             Project: FOP
>          Issue Type: Bug
>    Affects Versions: 2.0
>         Environment: At least Mac and Linux, both Oracle VM and OpenJDK
>            Reporter: Jeremy Smith
>            Assignee: simon steiner
>            Priority: Minor
>         Attachments: FOP-2525.patch, FOP_patch_heap-usage.png, 
> removestatic2.patch
>
>
> When a TrueType Collection file is used to specify custom fonts, and a 
> long-running FopFactory is used to create FOP instances to process many FO 
> input documents, millions of 
> org.apache.fop.complexscripts.fonts.GlyphPositioningTable$PairValues and 
> org.apache.fop.complexscripts.fonts.GlyphPositioningTable$Values instances 
> get created which are never collected.  Thus the heap continues to grow, 
> leading to eventual GC thrashing or crash.
> When the same fonts are used, but extracted from the TTC file, the issue does 
> not occur, and the instances of those classes are collected normally.
> The issue can be seen by repeatedly processing a document with a config.xml 
> which specifies fonts inside of a Truetype Collection file.  Attaching 
> VisualVM to such a process will show continuous heap growth and millions of 
> aforementioned instances whose numbers never decrease.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to