You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Alexios Giotis <al...@gmail.com> on 2011/09/08 11:09:03 UTC
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
Re: Memory leak in FOP
Posted by Simon Pepping <sp...@leverkruid.eu>.
On Thu, Sep 08, 2011 at 05:33:44PM +0300, Alexios Giotis wrote:
>
> It would be good if Apache FOP created bug-fix releases sooner.
Indeed, it would. That, and processing patches faster, would be
possible if FOP would have more committers.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Memory leak in FOP
Posted by Jonathan Levinson <Jo...@intersystems.com>.
Thank you Alexios!
Best Regards,
Jonathan Levinson
> -----Original Message-----
> From: Alexios Giotis [mailto:alex.giotis@gmail.com]
> Sent: Thursday, September 08, 2011 10:34 AM
> To: fop-users@xmlgraphics.apache.org
> 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: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
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Memory leak in FOP
Posted by Alexios Giotis <al...@gmail.com>.
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
Re: Memory leak in FOP
Posted by "Terence M. Bandoian" <te...@tmbsw.com>.
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
RE: Memory leak in FOP
Posted by Jonathan Levinson <Jo...@intersystems.com>.
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
RE: Memory leak in FOP
Posted by Jonathan Levinson <Jo...@intersystems.com>.
I ran YourKit on FOP and looked at memory telemetry and did not see any leak.
I think the apparent leak I saw was a result of data not yet being garbage collected.
Thanks for the advice about sharing a FOPFactory instance between threads.
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