Hi Jeremias,

> On 06.12.2008 20:00:01 thomas.deweese wrote:

> > 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.

Jeremias Maerki <[EMAIL PROTECTED]> wrote on 12/07/2008 06:17:48 AM:

> 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.

   The window where this particular problem occurs is fairly small,
once the CSS Engine has been set all the properties it shouldn't have
this problem.

> 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?

   But every SVG document has CSS parts, that is why we have to build
the CSS engine.  What I'm not sure of is how thread safe all 'read'
operations are.  It has never been a goal/design objective of Batik to 
make the DOM thread safe for 'read' operations.  This sounds like an
easy thing but for graphics it is often important to lazily construct
some items.

> >    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.

   As I mentioned in the other thread.  The infoset of the DOM should
not be touched, it's primarily the internal structures that support the
various 'extended' DOM interfaces (CSS & SVG) that are likely to be
problematic.  So I think that a deep clone should be ok, but always 
cloning is of course safer (and perhaps simpler).

> I hope the performance penalty for the cloning is not too high.

   The clone is _much_ faster than the initial parse (10->100x faster).

> 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?

   Anything is possible, but it would be a huge effort. 

   If you really want to share the documents you might be able to 
'prepare' 
the document in a single thread (as part of the load operation) and then 
render in multiple threads.  But honestly even that would make me nervous
due to lazily constructed objects in the CSS Engine and GVT tree.

> > > 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.

  Ok.

> > > 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]
> 

Reply via email to