Thanks for your input, Thomas! On 06.12.2008 20:00:01 thomas.deweese wrote: > Hi Jeremias, > > Jeremias Maerki <[EMAIL PROTECTED]> wrote on 12/05/2008 03:55:42 AM: > > > I can reproduce the issue with this test case. It really only happens in > > the multi-threading case (running against Batik Trunk). As soon as you > > place break-points before the exception (NumberFormatException) can > > happen, it won't. I'm not sure where to start looking for the problem. > > Maybe we can do something in FOP to avoid this. Help/hints would be > > appreciated. > > I don't know how FOP loads and rasterizes SVG documents. If there > is a global cache of Documents that have been read so the same Document > Object ends up being used in both threads that would cause this problem.
Hmm, I wonder why we've never had that before (to my knowledge). After all we have an image cache which caches and reuses the SVG DOM for years. Even FOP versions before 0.20.5 did that. I mean I can understand that SVGs with scripts or animation might modify the DOM but static SVGs with no script, no animation, no CSS parts? Anyway, FOP does have (0.94 or earlier) an image cache or uses the one in the image loading framework from XML Graphics Commons (since FOP 0.95). In the case of SVG documents, the DOM is reused with the intention of improving performance. > Checking the source it appears that fop.image.ImageFactory does this. You're looking at old source code (before 0.95). This has been replaced by the XG Commons image loading framework. http://xmlgraphics.apache.org/commons/image-loader.html > There seem to be some options for sharing (or not) of images between > contexts but it's not obvious to me how that works. Images are cached with their original URI as the key. When the same URI is requested the cached image (with a reference to the SVG DOM) is returned if it hasn't already been claimed by the garbage collector. Image subclasses indicate if they are cacheable or not: https://svn.eu.apache.org/viewvc/xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/image/loader/Image.java?view=markup > Another option would be to deep clone the Document the second time > (deciding that it's the second time is left as an exercise for the > user of Batik ;). That depends. If you're saying that the DOM can actually be manipulated, even in case of a "static" SVG, then that might not always be a good idea. To be on the safe side, I think I'll always have to clone the SVG document. I hope the performance penalty for the cloning is not too high. Do you think it is feasible to modify Batik to treat the SVG document as read-only? If yes, where would we have to dive in? > > Peter, there's one problem in your test case: You reuse the FOUserAgent > > for all documents. That's not how it's supposed to be. You have to > > create a new FOUserAgent for each processing run. Too bad, that doesn't > > already fix the problem. ;-) > > This might let the 'context' stuff I mentioned above kick in. No, the image cache is attached to the FopFactory, not the FOUserAgent. The old image cache used to create a hard reference on an image when it was preloaded during layout to block garbage collection. That hard reference was released (leaving the soft reference in the image cache) when the image was rendered. I didn't reimplement that feature to lower the memory requirements for images that have to be fully loaded at "pre-loading time". > > > > > On 04.12.2008 23:58:57 Peter Coppens wrote: > > > > > > We have been able to reproduce with the following files > > > > > > http://www.nabble.com/file/p20844449/TestPijltje.java TestPijltje.java > > > > http://www.nabble.com/file/p20844449/pols.xml pols.xml > > > http://www.nabble.com/file/p20844449/pols.xslt pols.xslt > > > http://www.nabble.com/file/p20844449/pijltje.svg pijltje.svg > > > > > > TestPijltje.java is the test program. It starts two threads each of > which > > > will generate a pdf based on the pols.xslt stylesheet, pols.xml en > > > pijltje.svg input file. > > > > > > If changing the code to only start one thread it always works fine. > With two > > > threads regular exceptions are thrown > > > > > > Stack trace is always something like > > > > > > Dec 4, 2008 11:54:33 PM org.apache.fop.svg.SVGUserAgent displayError > > > SEVERE: SVG Errorfile:/Users/pc/Downloads/fop-0.95/pijltje.svg: > > > The attribute "enable-background" represents an invalid CSS value > ("new 0 0 > > > 47.403 26.361"). > > > Original message: > > > Invalid number. > > > org.w3c.dom.DOMException: > file:/Users/pc/Downloads/fop-0.95/pijltje.svg: > > > The attribute "enable-background" represents an invalid CSS value > ("new 0 0 > > > 47.403 26.361"). > > > Original message: > > > Invalid number. > > > 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.convertVisibility(Unknown > > > Source) > > > at > > > org.apache.batik.bridge.SVGSVGElementBridge.createGraphicsNode(Unknown > > > Source) > > > at org.apache.batik.bridge.GVTBuilder.build(Unknown Source) > > > at > > > org.apache.fop.render.pdf.PDFSVGHandler. > > renderSVGDocument(PDFSVGHandler.java:188) > > > > > > > > > Any help warmly welcomed! > > > > > > Thanks > > > > > > Peter > > > > > > > > > -- > > > View this message in context: http://www.nabble.com/Batik- > > exception-when-using-fop-with-svg-images-in-threaded-environment- > > tp20809049p20844449.html > > > Sent from the Batik - Users mailing list archive at Nabble.com. > > > > > > > > > > > > > > Jeremias Maerki > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
