As in another post mentioned - I have been debugging the code. The dom is not modified. The dom caches a Parser object which is not thread safe.
> From: Jeremias Maerki <[EMAIL PROTECTED]> > Reply-To: <[email protected]> > Date: Sun, 07 Dec 2008 12:17:48 +0100 > To: <[email protected]> > Subject: Re: Batik exception when using fop with svg images in threaded > environment > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
