You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Manuel Mall <mm...@arcus.com.au> on 2007/10/16 18:32:34 UTC
RE: svn commit: r585167 - /xmlgraphics/fop/trunk/src/java/org/apa
che/fop/render/PrintRendererConfigurator.java
> -----Original Message-----
> From: Chris Bowditch [mailto:bowditch_chris@hotmail.com]
>
>
> jeremias@apache.org wrote:
>
> > Author: jeremias
> > Date: Tue Oct 16 08:12:45 2007
> > New Revision: 585167
> >
> > URL: http://svn.apache.org/viewvc?rev=585167&view=rev
> > Log:
> > Bugfix: If auto-detection is enabled, auto-detection didn't
> get done starting with the second rendering run in the same
> JVM. Static variables are dangerous!
>
> Hi Jeremias,
>
> auto detecting the Fonts is a very expensive operation. I'm
> not sure I
> want it to happen everytime I create an instance of a
> Renderer object.
> The way Adrian implemented it avoided calling this expensive
> operation
> each time a Renderer was implemented. The drawback is that if
> the Fonts
> are changing on a regular basis on the system then theres no
> way to tell
> FOP to refresh its auto-detected Fonts without restarting the JVM.
> Perhaps we need some sort of method which allows the
> auto-detected Fonts
> to be refreshed.
>
I agree with Chris' comment here as I use fop in a heavy multi-threaded
server app and I certainly would not like the performance hit of font
detection for each rendering run. After an admittedly very cursory look at
the font detection code and the use of the font cache I am concerned that
this whole area may not be thread safe. For example the font cache is based
on a normal Java HashMap. While the font cache code protects the map against
concurrent updates it does not prevent a lookup concurrent to an update.
This is known to cause endless loops in the HashMap.get() operation. Of
course the static variable Jeremias removed was also a multi-threading
'hazard' and if reintroduced need to be protected appropriately.
> Chris
>
Manuel
Re: svn commit: r585167 - /xmlgraphics/fop/trunk/src/java/org/apa che/fop/render/PrintRendererConfigurator.java
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Oct 16, 2007, at 18:32, Manuel Mall wrote:
>> jeremias@apache.org wrote:
>>
>>> Author: jeremias
>>> Date: Tue Oct 16 08:12:45 2007
>>> New Revision: 585167
>>>
>>> URL: http://svn.apache.org/viewvc?rev=585167&view=rev
>>> Log:
>>> Bugfix: If auto-detection is enabled, auto-detection didn't
>> get done starting with the second rendering run in the same
>> JVM. Static variables are dangerous!
>>
>> Hi Jeremias,
>>
>> auto detecting the Fonts is a very expensive operation. I'm
>> not sure I
>> want it to happen everytime I create an instance of a
>> Renderer object.
> <snip />
> I agree with Chris' comment here as I use fop in a heavy multi-
> threaded
> server app and I certainly would not like the performance hit of font
> detection for each rendering run.
I agree as well, with both points. Jeremias is very right to be
concerned about statics. Maybe a Singleton tied to the FopFactory
could ease the pains here: no statics, and yet only initialized once.
Add a utility method to the FopFactory if we really need the
possibility to refresh.
Cheers
Andreas