Hi Jeremias, > The Service class is properly synchronized.
I downloaded the source, and agree. > The ElementMapping > classes, however, are recreated for each FopFactory. There's no > sharing of these classes between multiple FopFactory instances. I downloaded the XML Graphics Common code. And I've reviewed the FOP code. I do not see it this way, see my further comments below... > 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. It's true, we have unique FOP instances, each with unique FopFactory instances, each with a unique ElementMappingRegistry instance. Where they all come together is in the ElementMappingRegistry static call to Service.providers(), which based on the code I saw in the XML Graphics Common 1.0 version of Service.java, would appear to return an Iterator over the _same_ statically cached list List, which then contains the same ElementMapping objects. Thus, the FopFactory objects end up using the same ElementMapping objects. The Service code appears to be using standard ArrayList and HashMap, so the Map.put()/Map.get() and List.iterator() method work normally (no behind the scenes cloning/copying going on). Further, it is directly placing a normal FOElementMapping instance into the list (no special wrapping going on). Should the Service be returning caller unique instances in the Iterator? If so, it needs to be re-written. The JavaDoc doesn't give me the feeling that is supposed to do this however. I only spent about 20 minutes looking over this, so I may have overlooked something? > 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 Yup, multi-processor box. That definately makes it easier to expose thread safety issues. I believe we were running about 5 thread max through the FOP code. Also we've only seen it once so far, it may be tricky to trigger. Tell you what, I'm due to take over working on our FOP related code in a couple weeks. When I do, I'll keep my eye out for this issue, and if I find out anything more, I'll do what I can to find the source and share what I find. In the meantime, we'll move to the non-deprecated API, and presume the issue is solved, until we get more Exceptions to prove otherwise. Thanks, Ryan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
