> -----Original Message----- > From: Chris Bowditch [mailto:[EMAIL PROTECTED] > > > [EMAIL PROTECTED] 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
