On 11.05.2006 18:09:24 Ryan Gustafson wrote: > Hi Jeremias, > > > 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. > > Thanks! I was not aware of this, I was just helping my colleague > debug the problem. I will inform him about this. We're looking for > ways to crank out more performance as it is! > > > 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? > > There are multiple threads using the same ElementMapping instances > (provided by the static cache in the "Service"). The ElementMapping > classes are not thread-safe.
The Service class is properly synchronized. The ElementMapping classes, however, are recreated for each FopFactory. There's no sharing of these classes between multiple FopFactory instances. Since you're using the deprecated Fop constructor a new FopFactory is instantiated for each new Fop instance. So I don't see why the ElementMapping classes need to be thread-safe. > A non-exhaustive list of solutions include: 1) The construction and > initalization of the ElementMappings should be done in the relative > thread-saftey of the static cache part of the code (e.g. in the > Service), and they would need to be used in an immutable fashion > after that. 2) If (1) is not possible, the ElementMapping objects > have to made thread-safe themselves. > > What strikes your fancy? I don't buy it, yet. I can see from your stack trace that something's wrong but I'm not sure you've found the right spot. What you can try is to synchronize ElementMapping.getTable() and check if this changes anything, but I just don't understand why two threads would modify the same HashMap in ElementMapping. I wish I could reproduce the problem. I've tried yesterday, but didn't succeed. I ran up to 60 threads in parallel with the deprecated constructor and had no problems. But on the other hand, I only had a single-processor machine to test on. Are you on a multi-processor box? Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
