xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexios Giotis <alex.gio...@gmail.com>
Subject Re: Memory leak in FOP
Date Thu, 08 Sep 2011 14:33:44 GMT
Synchronizing the access to FopFactory will not help. For example, the FOUserAgent returned
by fopFactory.newFOUserAgent() contains inside a reference to the fopFactory instance.

What would help is to reuse (but not at the same time) the fopFactory instances by keeping
them in a pool. When a thread is going to process an XSL:FO, it will get an available fopFactory
instance, create userAgent etc and after rendering, it will return the fopFactory back in
to the pool.

I had a quick look in our branch and I did not find any other concurrency related issues,
than the 3 I mentioned below. If you create big PDF files, it will save you some memory by
also applying the change in http://svn.apache.org/viewvc?view=revision&revision=1052214
( http://marc.info/?l=fop-dev&m=129327880722491&w=2 ).

It would be good if Apache FOP created bug-fix releases sooner.

Alexios Giotis


On Sep 8, 2011, at 5:01 PM, Terence M. Bandoian wrote:

> On 9/8/2011 8:45 AM, Jonathan Levinson wrote:
>> The reason we share a FopFactory instance between threads is speed.  FopFactory creation
is very expensive.  I believe it involves font look ups.
>> 
>> Perhaps we should go the private branch approach, just applying to FOP 1.0, the fixes
to the thread-safety issue.  Thanks for the beginnings of such a list, but would you mind
sharing the complete list, or instructing me on how I can construct a complete list?
>> 
>> Best Regards,
>> Jonathan Levinson
>> 
>> 
>>> -----Original Message-----
>>> From: Alexios Giotis [mailto:alex.giotis@gmail.com]
>>> Sent: Thursday, September 08, 2011 5:09 AM
>>> To: fop-users@xmlgraphics.apache.org
>>> Subject: Re: Memory leak in FOP
>>> 
>>> Hi Jonathan,
>>> 
>>> We are running FOP multi-threaded in many production systems. Each system is
>>> creating thousand documents per day (typically 100 -500 thousand PDFs) and I
>>> have not noticed any memory leak. Having said that, our servers are running
>>> with large memory heaps (6-10GB), FOP uses a lot of memory for large
>>> documents and internal caches for performance.
>>> 
>>> If you are going to use it at production, I would recommend not to share the
>>> same FopFactory instance between threads. It is supposed to the thread-safe
>>> but we found (and in most cases fixed in trunk) several issues. You could try
the
>>> FOP trunk or you could apply the patches for the related issues in your own
>>> private branch (this is what we do). Some issues that I remember:
>>> 
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50698  (starting from
>>> http://marc.info/?l=fop-user&m=129646673801270&w=2)
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=46360
>>> 
>>> and lately a deadlock that I am waiting for someone to review the patch:
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=46962
>>> 
>>> Best Regards,
>>> Alexis Giotis
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Sep 7, 2011, at 7:31 PM, Jonathan Levinson wrote:
>>> 
>>>> To speed up FOP rendering, I have developed a multi-threaded program that
>>> initializes a FOP factory and shares it amongst the thread instances.
>>>> We experience a large performance increase because we are not starting a
>>> JVM on each instance of FOP rendering and we are not creating a FOPFactory
>>> for each thread but sharing a FOPFactory amongst threads.
>>>> Testing on LINUX and using the following command to examine memory:
>>>> 
>>>> ps -e -orss=,args= | sort -b -k1,1n | pr -TW$COLUMNS
>>>> 
>>>> I notice a slow memory memory leak.
>>>> 
>>>> The test sends the same xml and xsl over and over again to the same multi-
>>> threaded program with its FOP factory instance.
>>>> Is this a well known problem in FOP?  Does FOP leak memory?
>>>> 
>>>> Best Regards,
>>>> Jonathan Levinson
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
> Hi, Jonathan-
> 
> It may be worth considering synchronizing the use of the FopFactory instance.
> 
> -Terence Bandoian
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Mime
View raw message