Mailing-List: contact batik-users-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: batik-users@xmlgraphics.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Sun, 07 Dec 2008 14:09:48 +0100
From: Jeremias Maerki <dev@jeremias-maerki.ch>
To: batik-users@xmlgraphics.apache.org
Subject: Re: Batik exception when using fop with svg images in threaded
 environment
In-Reply-To: 
 <OFECAC10B5.6AFFEF90-ON85257518.00455342-85257518.0046C9CA@knotes.kodak.com>
References: <20081207124348.9ACB.60BA733C@jeremias-maerki.ch>
 <OFECAC10B5.6AFFEF90-ON85257518.00455342-85257518.0046C9CA@knotes.kodak.com>
Message-Id: <20081207140532.9ADD.60BA733C@jeremias-maerki.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Thanks a lot, Thomas. So the safest way would be to clone the (cached) SVG
document. As an optimization step one could investigate if some sort of
caching the GVT tree is doable (see my other post just a few minutes ago).
I assume the second option would take quite a bit of effort (including
benchmarks beforehand to determine the optimization potential).

On 07.12.2008 13:53:12 thomas.deweese wrote:
> Hi Jeremias,
>=20
> Jeremias Maerki <dev@jeremias-maerki.ch> wrote on 12/07/2008 06:53:04 AM:
>=20
> > Is that a sure thing that the DOM is not modified?=20
>=20
>    It is 100% certain that you can't have one document with
> two attached GVT tree's - which I think you would need to do
> with your current approach.  The actual DOM infoset shouldn't
> be modified but internally we attach additional structures to
> handle the CSS & SVG DOMs.  Also some items (particularly in
> the SVG DOM) may be lazily constructed (so the two threads might
> collide when 'reading' those items).
>=20
> > If yes, we'd have to ask the question whether attaching the CSS engine=
=20
> > to the DOM is the right thing to do. And is the CSS Engine as such not=
=20
> > thread-safe or is only the setting of the CSS engine not thread safe=20
> (method
> > BridgeContext.initializeDocument(Document))?=20
>=20
>    Once again no attempt was made to make the CSS Engine thread safe, it
> might be thread safe for some set of operations but I can't give any kind
> of guidelines.  Of course you must attach the CSS Engine otherwise the=20
> CSS DOM (which we use to render the document) won't be available.
>=20
>    In Batik it is 100% required that people access DOM/CSS/GVT through=20
> one thread.
>=20
> > Maybe an idea could be to attach the CSS engine to the thread (thread=
=20
> > local) instead of to the DOM if only one thread uses the CSS engine in=
=20
> > a single rendering run and the CS engine is not thread-safe.=20
> > Just brain-storming....
>=20
>    The only thing that might work would be to attach the CSSEngine once
> and build the GVT tree once and keep that in the cache.  But even with
> that the GVT tree may well not support multiple concurrent renderings
> (although for a static document it should come close).
>=20
> > On 07.12.2008 12:32:43 Peter Coppens wrote:
> > > As in another post mentioned - I have been debugging the code. The do=
m=20
> is
> > > not modified. The dom caches a Parser object which is not thread safe.
> > >=20
> > >=20
> > > > From: Jeremias Maerki <dev@jeremias-maerki.ch>
> > > > Reply-To: <batik-users@xmlgraphics.apache.org>
> > > > Date: Sun, 07 Dec 2008 12:17:48 +0100
> > > > To: <batik-users@xmlgraphics.apache.org>
> > > > Subject: Re: Batik exception when using fop with svg images in=20
> threaded
> > > > environment
> > > >=20
> > > > Thanks for your input, Thomas!
> > > >=20
> > > > On 06.12.2008 20:00:01 thomas.deweese wrote:
> > > >> Hi Jeremias,
> > > >>=20
> > > >> Jeremias Maerki <dev@jeremias-maerki.ch> wrote on 12/05/2008=20
> 03:55:42 AM:
> > > >>=20
> > > >>> I can reproduce the issue with this test case. It really only=20
> happens in
> > > >>> the multi-threading case (running against Batik Trunk). As soon a=
s=20
> you
> > > >>> place break-points before the exception (NumberFormatException)=
=20
> can
> > > >>> happen, it won't. I'm not sure where to start looking for the=20
> problem.
> > > >>> Maybe we can do something in FOP to avoid this. Help/hints would=
=20
> be
> > > >>> appreciated.
> > > >>=20
> > > >>    I don't know how FOP loads and rasterizes SVG documents.  If=20
> there
> > > >> is a global cache of Documents that have been read so the same=20
> Document
> > > >> Object ends up being used in both threads that would cause this=20
> problem.
> > > >=20
> > > > Hmm, I wonder why we've never had that before (to my knowledge).=20
> After
> > > > all we have an image cache which caches and reuses the SVG DOM for=
=20
> years.
> > > > Even FOP versions before 0.20.5 did that.
> > > >=20
> > > > I mean I can understand that SVGs with scripts or animation might=
=20
> modify
> > > > the DOM but static SVGs with no script, no animation, no CSS parts?
> > > >=20
> > > > Anyway, FOP does have (0.94 or earlier) an image cache or uses the=
=20
> one
> > > > in the image loading framework from XML Graphics Commons (since FOP=
=20
> 0.95).
> > > > In the case of SVG documents, the DOM is reused with the intention=
=20
> of
> > > > improving performance.
> > > >=20
> > > >>    Checking the source it appears that fop.image.ImageFactory does=
=20
> this.
> > > >=20
> > > > You're looking at old source code (before 0.95). This has been=20
> replaced
> > > > by the XG Commons image loading framework.
> > > > http://xmlgraphics.apache.org/commons/image-loader.html
> > > >=20
> > > >> There seem to be some options for sharing (or not) of images=20
> between
> > > >> contexts but it's not obvious to me how that works.
> > > >=20
> > > > Images are cached with their original URI as the key. When the same=
=20
> 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=3Dmarkup
> > > >=20
> > > >>    Another option would be to deep clone the Document the second=
=20
> time
> > > >> (deciding that it's the second time is left as an exercise for the
> > > >> user of Batik ;).
> > > >=20
> > > > That depends. If you're saying that the DOM can actually be=20
> manipulated,
> > > > even in case of a "static" SVG, then that might not always be a goo=
d
> > > > idea. To be on the safe side, I think I'll always have to clone the=
=20
> SVG
> > > > document.
> > > >=20
> > > > I hope the performance penalty for the cloning is not too high.
> > > >=20
> > > > Do you think it is feasible to modify Batik to treat the SVG=20
> document as
> > > > read-only? If yes, where would we have to dive in?
> > > >=20
> > > >>> Peter, there's one problem in your test case: You reuse the=20
> FOUserAgent
> > > >>> for all documents. That's not how it's supposed to be. You have t=
o
> > > >>> create a new FOUserAgent for each processing run. Too bad, that=
=20
> doesn't
> > > >>> already fix the problem. ;-)
> > > >>=20
> > > >>    This might let the 'context' stuff I mentioned above kick in.
> > > >=20
> > > > No, the image cache is attached to the FopFactory, not the=20
> FOUserAgent.
> > > > The old image cache used to create a hard reference on an image whe=
n=20
> it
> > > > was preloaded during layout to block garbage collection. That hard
> > > > reference was released (leaving the soft reference in the image=20
> cache)
> > > > when the image was rendered. I didn't reimplement that feature to=
=20
> lower
> > > > the memory requirements for images that have to be fully loaded at
> > > > "pre-loading time".
> > > >=20
> > > >>=20
> > > >>>=20
> > > >>> On 04.12.2008 23:58:57 Peter Coppens wrote:
> > > >>>>=20
> > > >>>> We have been able to reproduce with the following files
> > > >>>>=20
> > > >>>> http://www.nabble.com/file/p20844449/TestPijltje.java=20
> TestPijltje.java
> > > >>=20
> > > >>>> 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
> > > >>>>=20
> > > >>>> TestPijltje.java is the test program. It starts two threads each=
=20
> of
> > > >> which
> > > >>>> will generate a pdf based on the pols.xslt stylesheet, pols.xml=
=20
> en
> > > >>>> pijltje.svg input file.
> > > >>>>=20
> > > >>>> If changing the code to only start one thread it always works=20
> fine.
> > > >> With two
> > > >>>> threads regular exceptions are thrown
> > > >>>>=20
> > > >>>> Stack trace is always something like
> > > >>>>=20
> > > >>>> Dec 4, 2008 11:54:33 PM org.apache.fop.svg.SVGUserAgent=20
> displayError
> > > >>>> SEVERE: SVG Errorfile:/Users/pc/Downloads/fop-0.95/pijltje.svg:
> > > >>>> The attribute "enable-background" represents an invalid CSS valu=
e
> > > >> ("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 valu=
e
> > > >> ("new 0 0
> > > >>>> 47.403 26.361").
> > > >>>> Original message:
> > > >>>> Invalid number.
> > > >>>>         at=20
> > > >> org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap(Unknown
> > > >>>> Source)
> > > >>>>         at=20
> > > >> org.apache.batik.css.engine.CSSEngine.getComputedStyle(Unknown
> > > >>>> Source)
> > > >>>>         at=20
> > > >> org.apache.batik.bridge.CSSUtilities.getComputedStyle(Unknown
> > > >>>> Source)
> > > >>>>         at=20
> > > >> org.apache.batik.bridge.CSSUtilities.convertVisibility(Unknown
> > > >>>> Source)
> > > >>>>         at
> > > >>>>=20
> org.apache.batik.bridge.SVGSVGElementBridge.createGraphicsNode(Unknown
> > > >>>> Source)
> > > >>>>         at org.apache.batik.bridge.GVTBuilder.build(Unknown=20
> Source)
> > > >>>>         at
> > > >>>> org.apache.fop.render.pdf.PDFSVGHandler.
> > > >>> renderSVGDocument(PDFSVGHandler.java:188)
> > > >>>>=20
> > > >>>>=20
> > > >>>> Any help warmly welcomed!
> > > >>>>=20
> > > >>>> Thanks
> > > >>>>=20
> > > >>>> Peter
> > > >>>>=20
> > > >>>>=20
> > > >>>> --=20
> > > >>>> 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.
> > > >>>>=20
> >=20
> >=20
> >=20
> > Jeremias Maerki
> >=20


Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org