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:[email protected]] >>> Sent: Thursday, September 08, 2011 5:09 AM >>> To: [email protected] >>> 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: [email protected] >>> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] > > Hi, Jonathan- > > It may be worth considering synchronizing the use of the FopFactory instance. > > -Terence Bandoian > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
