FOP reuses/caches SVG documents to improve performance. But as we had to learn, this approach is not thread-safe as Batik attaches some facilities (like the CSS engine) to the DOM which are not thread-safe. The detailed discussion of the issue can be found here: http://markmail.org/message/2dk2ib4e5t6vfsrl The safest approach is to clone the SVG DOM prior to passing it to Batik. Obviously that will cost a bit of performance and increase memory usage a bit. If we're careful and have the resources to implement that we can improve performance by caching Batik's GVT tree. Ideas can also be found in the thread indicated above.
Issue fixed as discussed on batik-users. http://svn.apache.org/viewvc?rev=724163&view=rev http://svn.apache.org/viewvc?rev=724164&view=rev I'll keep this open for a bit since I'll have to do the same in the IF branch.
One more note to self: Need to introduce a flag to indicate whether we're working off a potentially cached SVG DOM or off a DOM that comes from an fo:instream-foreign-object in which the cloning is unnecessary.
I got a NullPointerException during FOP processing while do transformations were processing concurrently. Both include (the same) SVG image files. ----------------- The attribute "style" represents an invalid CSS declaration ("fill:#ef7b00; fill-rule:nonzero; stroke:none; stroke-width:1; stroke-linecap:butt; stroke-linejoin:miter; stroke-dasharray:none;"). Original message: java.lang.NullPointerException org.w3c.dom.DOMException: file:/C:/Programme/ddf/xml/images/V10271.svg: The attribute "style" represents an invalid CSS declaration ("fill:#ef7b00; fill-rule:nonzero; stroke:none; stroke-width:1; stroke-linecap:butt; stroke-linejoin:miter; stroke-dasharray:none;"). Original message: java.lang.NullPointerException at org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap(Unknown Source) at org.apache.batik.css.engine.CSSEngine.getComputedStyle(Unknown Source) at org.apache.batik.bridge.CSSUtilities.getComputedStyle(Unknown Source) at org.apache.batik.bridge.CSSUtilities.convertDisplay(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source) at org.apache.batik.bridge.GVTBuilder.build(Unknown Source) at org.apache.fop.render.pdf.PDFSVGHandler.renderSVGDocument(PDFSVGHandler.java:188) --------------------------------------- see https://issues.apache.org/bugzilla/show_bug.cgi?id=46418 I guess, there are more threading issues with Batik SVG...
A similar bug has been fixed in FOP Trunk as is noted in this bug. Does this error occur with the current FOP Trunk? (In reply to comment #3) > I got a NullPointerException during FOP processing while do transformations > were processing concurrently. Both include (the same) SVG image files. > > ----------------- > The attribute "style" represents an invalid CSS declaration ("fill:#ef7b00; > fill-rule:nonzero; stroke:none; stroke-width:1; stroke-linecap:butt; > stroke-linejoin:miter; stroke-dasharray:none;"). > Original message: > java.lang.NullPointerException > org.w3c.dom.DOMException: file:/C:/Programme/ddf/xml/images/V10271.svg: > The attribute "style" represents an invalid CSS declaration ("fill:#ef7b00; > fill-rule:nonzero; stroke:none; stroke-width:1; stroke-linecap:butt; > stroke-linejoin:miter; stroke-dasharray:none;"). > Original message: > java.lang.NullPointerException > at org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap(Unknown > Source) > at org.apache.batik.css.engine.CSSEngine.getComputedStyle(Unknown > Source) > at org.apache.batik.bridge.CSSUtilities.getComputedStyle(Unknown > Source) > at org.apache.batik.bridge.CSSUtilities.convertDisplay(Unknown Source) > at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source) > at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source) > at org.apache.batik.bridge.GVTBuilder.build(Unknown Source) > at > org.apache.fop.render.pdf.PDFSVGHandler.renderSVGDocument(PDFSVGHandler.java:188) > > --------------------------------------- > > see https://issues.apache.org/bugzilla/show_bug.cgi?id=46418 > > I guess, there are more threading issues with Batik SVG... >
As this is a multi-threading issue, it's hard to reproduce. I throw lots of jobsat the application but wasn't able to reproduce it for now (with FOP 0.95).
I can confirm that this issue is valid for FOP 1.0. A workaround is to use a different instance of FopFactory per thread.
Created attachment 25970 [details] Patch to clone the SVG document inside PDFImageHandlerSVG The patch is attached after a short discussion in the fop-dev mailing list. Shortly, in PDFImageHandlerSVG.handleImage() the SVG document is not cloned but in other places it is. Examples of cloning are in ImageConverterSVG2G2D, AbstractGenericSVGHandler, AFPImageHandlerSVG, AFPSVGHandler, Java2DSVGHandler, PSSVGHandler. Before the patch, in a multi-threaded environment parsing of the SVG documents was corrupted with a probability close to 80%. After this, the errors can not be reproduced. This patch contains the smallest change I could do, is for a single file and should be safe to apply. On a side note, normally I would first try to gather the building of the GraphicsNode in a single place and then avoid the document cloning by serializing only the parsing of the SVG. But that would affect more files / projects and would make the processing of the patch more difficult.
Patch applied: http://svn.apache.org/viewvc?rev=997599&view=rev Thanks, Alexis. One more fix here: http://svn.apache.org/viewvc?rev=997602&view=rev That should now be all.