[
https://issues.apache.org/jira/browse/FOP-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18082501#comment-18082501
]
Ben commented on FOP-3313:
--------------------------
Hi [~ssteiner]
Again, I don't follow the intention of what you're suggesting. Looking at
DefaultFontConfigurator.configure, the font cache is only populated AFTER font
autodetection, whereas from the stack trace above the fonts are failing to be
read DURING font autodetection.
And again, I don't really see why I should want to disable font caching.
Rather, I think I DO want font caching, and, again, font autodetection, but I
just want that autodetection to be guaranteed thread-safe...
Thanks
> Multi-threaded FOP usage breaks FontLoader
> ------------------------------------------
>
> Key: FOP-3313
> URL: https://issues.apache.org/jira/browse/FOP-3313
> Project: FOP
> Issue Type: Bug
> Components: font/unqualified, renderer/pdf
> Affects Versions: 2.4
> Reporter: Ben
> Priority: Major
>
> I'm trying to convert our usage of Apache FOP from a single-threaded
> implementation to a multi-threaded one.
> We have a process that generates PDF documents for every item in a large
> dataset, and this is creating a performance bottleneck: each item takes about
> 200ms to generate using FOP in out single-threaded implementation.
> The wrapper class by which we use FOP, FopConfiguration, declares a
> {{FopFactory}} field. I've now converted it to a {{{}private
> ThreadLocal<FopFactory> factory{}}}.
> I have a font directory that the FOP factory needs to load custom fonts from.
> This directory is initialised once, and then passed to the code that
> instantiates the ThreadLocal.
> I would expect switching to ThreadLocal for the FopFactory would be
> sufficient, but what I'm instead seeing is that when {{agent.newFop}} is
> called, it's causing {{org.apache.fop.fonts.FontLoader#read}} to be called
> within that thread.
> There seems to be some resource contention within that method, because in
> contrast to the single-threaded wrapper, the multi-threaded wrapper is
> failing at {{OpenFont.readCMAP}} with the following error:
> Unsupported TrueType font: No Unicode or Symbol cmap table not present.
> Aborting
> So it seems like the FOP agent is lazy-loading some fonts, and doing so isn't
> thread-safe?
>
> {code:java}
> at org.apache.fop.fonts.truetype.OpenFont.readCMAP(OpenFont.java:443)
> at org.apache.fop.fonts.truetype.OpenFont.readFont(OpenFont.java:846)
> at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:117)
> at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:101)
> at org.apache.fop.fonts.FontLoader.getFont(FontLoader.java:126)
> at
> org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:227)
> at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63)
> at
> org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(FontDetectorFactory.java:105)
> at org.apache.fop.fonts.FontManager.autoDetectFonts(FontManager.java:229)
> at
> org.apache.fop.fonts.DefaultFontConfigurator.configure(DefaultFontConfigurator.java:82)
> at
> org.apache.fop.render.PrintRendererConfigurator.getCustomFontCollection(PrintRendererConfigurator.java:147)
> at
> org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:127)
> at org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:170)
> at
> org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:187)
> at org.apache.fop.area.RenderPagesModel.<init>(RenderPagesModel.java:75)
> at org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:135)
> at org.apache.fop.area.AreaTreeHandler.<init>(AreaTreeHandler.java:105)
> at
> org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:363)
> at org.apache.fop.fo.FOTreeBuilder.<init>(FOTreeBuilder.java:107)
> at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:104)
> at org.apache.fop.apps.Fop.<init>(Fop.java:78)
> at org.apache.fop.apps.FOUserAgent.newFop(FOUserAgent.java:183)
> {code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
