Thank you Alexios! Best Regards, Jonathan Levinson
> -----Original Message----- > From: Alexios Giotis [mailto:[email protected]] > Sent: Thursday, September 08, 2011 10:34 AM > To: [email protected] > Subject: Re: Memory leak in FOP > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
