xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: fop-0.92.beta: Thread safety issues with FOP instance construction
Date Thu, 11 May 2006 07:22:29 GMT
Looks like you're still using one of the deprecated Fop constructors.
Please be aware that they will be remove for the next release.
Furthermore, you're giving a way performance by not reusing the
FopFactory. See [1] for the documentation on the new finalized API.

Obviously, that's not an excuse for the exception but at least I'm
pretty sure it's the solution for your current problem. I'm confused
myself why this exception occurs in the first place. By means of static
code analysis I cannot find any evidence of poor use of static variables
that could lead to this exception. The "Service" stuff is properly
synchronized and the FOElementMapping stuff is purely non-static. Does
anyone have an idea what's wrong here?

[1] http://xmlgraphics.apache.org/fop/latest/embedding.html

On 11.05.2006 01:18:02 Ryan Gustafson wrote:
> Hello,
> When processing many concurrent JMS messages which use FOP, we have
> encountered the following exception when constructing an FOP
> instance:
> Caused by: java.util.ConcurrentModificationException: concurrent
> access to HashMap attempted by Thread[MessageListenerThreadPool :
> 2,5,main]
> 	at java.util.HashMap.onExit(HashMap.java(Inlined Compiled
> Code))
> 	at java.util.HashMap.transfer(HashMap.java(Compiled Code))
> 	at java.util.HashMap.resize(HashMap.java(Inlined Compiled
> Code))
> 	at java.util.HashMap.addEntry(HashMap.java(Compiled Code))
> 	at java.util.HashMap.put(HashMap.java(Compiled Code))
> 	at
> org.apache.fop.fo.FOElementMapping.initialize(FOElementMapping.java:62)
> 	at
> org.apache.fop.fo.ElementMapping.getTable(ElementMapping.java:50)
> 	at
> org.apache.fop.fo.ElementMappingRegistry.addElementMapping(ElementMappingRegistry.java:117)
> 	at
> org.apache.fop.fo.ElementMappingRegistry.setupDefaultMappings(ElementMappingRegistry.java:76)
> 	at
> org.apache.fop.fo.ElementMappingRegistry.<init>(ElementMappingRegistry.java:63)
> 	at
> org.apache.fop.apps.FopFactory.<init>(FopFactory.java:118)
> 	at
> org.apache.fop.apps.FopFactory.newInstance(FopFactory.java:126)
> 	at org.apache.fop.apps.Fop.<init>(Fop.java:113)
> First, I examined our code look for threading issues.  I wasn't able
> to find any obvious issues.
> Then, I examined the FOP code listed in the stack trace.  My gut
> feeling is that the line 71 in ElementMappingRegistry:
>         Iterator providers =
> Service.providers(ElementMapping.class);
> is returning statically cached data structures (it is a static
> method call), which the FOP code then uses in a non-threadsafe
> fashion.
> Anyway, just a heads up.
> I'll suggest we try to work around the issue on our end by
> synchronizing the FOP instance constructions in our code.

Jeremias Maerki

To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

View raw message