Re: Memory Leak issue -- FOP

[Hamed Mohammed]

Hi,

This is how I am using FOP to process XSL.FO into PDF. I agree that
the issue is to do with too much of memory consumption. Is there a better
way to process this large FO file into PDF using FOP?

String xml = builder.getReport(); /// gets the XSL:FO file data approx 50mb

PdfStorage pdfHolder = pdfStorageFactory.createStorage(reportRequest,

contentType);

pdfMaker.generatePDF(pdfHolder, xml);  // Instance of PdfCreator injected
through Spring.


On Mon, Aug 30, 2010 at 1:07 AM, Dominik Stadler <
dominik.stad...@dynatrace.com> wrote:

>
> Hi,
>
> Craig is right, it's it's not a "memory leak", but rather memory kept
> active too long, i.e. after processing is done. I saw the same thing when I
> integrated FOP into an application over here.
>
> It is basically caused by the SAX implementation that you use as it caches
> the SAX-Handler, where the FOP-SAX-Handler keeps references to a lot of
> internal stuff. In my case it did this in a ThreadLocal, so with different
> threads using FOP I ended up having this memory kept in every thread, which
> accumulated to quite an amount of memory depending on the usage pattern.
>
> I tried various different ways to solve this, when using SAX/XML provided
> as part of Sun JDK 1.6 the following was removing this memory bloat:
>
>                Result result = new SAXResult(fop.getDefaultHandler());
>                SAXSource source = new SAXSource(inputSource);
>                // set our own XMLReader to prevent Sun XML from caching
> stuff in ThreadLocals which keeps FOP in memory
>                // we want to free up any FOP resources when not reporting
> and for this ThreadLocals is very bad, especially
>                // as we are called in different threads via REST and
> Scheduling thread pools!
>                source.setXMLReader(XMLReaderFactory.createXMLReader());
>
>                transformer.transform(source, result);
>
>                if (logger.isLoggable(Level.FINE) && fop.getResults() !=
> null) {
>                        logger.info("Processing resulted in " +
> fop.getResults().getPageCount() + " pages."); //$NON-NLS-1$ //$NON-NLS-2$
>                }
>        }
>
> Maybe a similar thing solves this for you as well.
>
> Dominik.
>
>
> -----Original Message-----
> From: Craig Ringer [mailto:cr...@postnewspapers.com.au]
> Sent: Donnerstag, 26. August 2010 02:35
> To: fop-users@xmlgraphics.apache.org
>  Cc: Hamed Mohammed
> Subject: Re: Memory Leak issue -- FOP
>
> On 26/08/2010 3:39 AM, Hamed Mohammed wrote:
> > Hello Users:
> > Any idea on how to solve the FOP memory leak issue. Below snap shots are
> > taken from Eclipse Memory Analyzer of a IBM portable heap dump.
>
> What makes you think that's a memory leak?
>
> It's a large amount of memory consumption, sure. But is there any
> evidence it's growing over time? Or growing whenever a new document is
> processed, without shinking again when the document is finished?
>
> How do you know it's not your own code keeping references to the fop
> instances around? Can you produce a small, self-contained program that
> demonstrates the leak?
>
> If your real question is "why is FOP using so much memory" ... well, to
> answer that it'd be necessary to know more about your XSL-FO input and
> the associated resources like graphics.
>
> --
> Craig Ringer
>
> Tech-related writing at http://soapyfrogs.blogspot.com/
>
>  ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
>
>
>
>


-- 
Thanks,
Hamed Mohammed,
Email: mohdhamedms...@gmail.com.