Re: Is org.apache.fop.apps.FopFactory thread safe ?
Hi Peter, Thanks for pointing this out. It differs in that the instance of FOUserAgent was shared, but other than this, it's exactly the same case. Finally, this leads to https://issues.apache.org/bugzilla/show_bug.cgi?id=46360 which is still open. As I read from the thread, this is a complex case and in batik they have good reasons not to be thread-safe. Finally, sorry for my other posting with the same title. I though that only the subscribed email address can post. Alexis On 1-9-10 11:30 PM, Peter Coppens wrote: Alexis, This reminds me of something similar I ran into a while ago. I can't remember the details nor how I eventually got around this and/or whether you run into the same but the (weird) behavior you describe does look very similar. See http://old.nabble.com/Batik-exception-when-using-fop-with-svg-images-in-threaded-environment-td20809049.html Perhaps it helps Peter On 01 Sep 2010, at 17:53, Alexios Giotis wrote: Hello, The javadoc and the class name suggest that FopFactory should be thread-safe although this is not explicitly written. If this is not thread-safe then please ignore what follows. I am using FOP 1.0 to produce PDF documents concurrently from FOP intermediate format. The PDF documents share a lot of common images, so I decided to use a single instance of FopFactory to reduce memory requirements. From the single FopFactory, I produce different instances for different threads like this: FOUserAgent userAgent = fopFactory.newFOUserAgent(); IFDocumentHandler targetHandler = fopFactory.getRendererFactory().createDocumentHandler(userAgent,outputFormat); IFUtil.setupFonts(targetHandler); targetHandler.setResult(new StreamResult(outStream)); IFConcatenator concatenator = new IFConcatenator(targetHandler, null); for (int i = 0; i numberOfDocumentsToConcatenate; i++) { Source src = new SAXSource(myOwnApplicationXmlFilters, new InputSource(myOwnInputStream)); concatenator.appendDocument(src); } The problem is that even on my 2-core laptop, I frequently get exceptions silently written in standard error. Different stacktraces are attached and as you can see happen when batik parses the SVG files. For the same input the strings read are corrupted. For example the overflow=visible is read as vssible and then later as vissibll. Also the fill=#EC2227 is try to parse E7E8 as color. The workaround for my application is to have a new instance of FopFactory per thread but I would like to fix it and create a patch. Since I am quite new to FOP, I would like some advise on what should be the proper level. The higher one would be the FopFactory (but it's too high and I could do it externally in my code), then there is the org.apache.xmlgraphics.image.loader.ImageManager and at the end we get to the very low level org.apache.batik.css.engine.CSSEngine or org.apache.batik.css.parser.Parser. Secondly, I think it's not a good practice that the exceptions are written in STDERR instead of propagating to the application. What do you think ? This is my first post to fop-dev and hopefully this is the proper one. Thanks, Alexis stacktraces.txt
Re: Is org.apache.fop.apps.FopFactory thread safe ?
Hi Alexis Thanks for the patch! I'll look at it shortly. Would you mind attaching it to the Bugzilla issue? https://issues.apache.org/bugzilla/show_bug.cgi?id=46360 That way it's clearer that you donate the changes to the ASF and everything concerning this problem is in one place. Thanks! On 02.09.2010 12:52:37 Alexios Giotis wrote: Jeremias, thanks for the clarification about the FopFactory. I had a look at your old commit at http://svn.apache.org/viewvc?view=revisionrevision=724163 The current situation in trunk is that 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. This should be the cause of all the stack traces I get. They all go through PDFImageHandlerSVG and after adding the document cloning (see attached patch), I can no longer reproduce the error. It should be safe to add the SVG document cloning in there but I would better reduce a little of code duplication. In all those places it is required to build a GraphicsNode and the way of doing this is similar. But maybe this is out of scope. Any suggestion on how to proceed with this ? On 2-9-10 11:28 AM, Jeremias Maerki wrote: Peter could be right. And there I thought I had this under control. But with so many open Bugzilla issues, things get lost quickly. I've seen multi-threading issues inside Batik myself in a production system and haven't been able to put my finger on it since I though I had this fixed, but it could be that I haven't really fixed it for all cases. I'll have to look into it. At any rate, FopFactory is supposed to be thread-safe. I always have one FopFactory instance per configuration and that is usually one for the whole JVM. On 02.09.2010 10:08:19 Alexios Giotis wrote: Hi Peter, Thanks for pointing this out. It differs in that the instance of FOUserAgent was shared, but other than this, it's exactly the same case. Finally, this leads to https://issues.apache.org/bugzilla/show_bug.cgi?id=46360 which is still open. As I read from the thread, this is a complex case and in batik they have good reasons not to be thread-safe. Finally, sorry for my other posting with the same title. I though that only the subscribed email address can post. Alexis On 1-9-10 11:30 PM, Peter Coppens wrote: Alexis, This reminds me of something similar I ran into a while ago. I can't remember the details nor how I eventually got around this and/or whether you run into the same but the (weird) behavior you describe does look very similar. See http://old.nabble.com/Batik-exception-when-using-fop-with-svg-images-in-threaded-environment-td20809049.html Perhaps it helps Peter On 01 Sep 2010, at 17:53, Alexios Giotis wrote: Hello, The javadoc and the class name suggest that FopFactory should be thread-safe although this is not explicitly written. If this is not thread-safe then please ignore what follows. I am using FOP 1.0 to produce PDF documents concurrently from FOP intermediate format. The PDF documents share a lot of common images, so I decided to use a single instance of FopFactory to reduce memory requirements. From the single FopFactory, I produce different instances for different threads like this: FOUserAgent userAgent = fopFactory.newFOUserAgent(); IFDocumentHandler targetHandler = fopFactory.getRendererFactory().createDocumentHandler(userAgent,outputFormat); IFUtil.setupFonts(targetHandler); targetHandler.setResult(new StreamResult(outStream)); IFConcatenator concatenator = new IFConcatenator(targetHandler, null); for (int i = 0; i numberOfDocumentsToConcatenate; i++) { Source src = new SAXSource(myOwnApplicationXmlFilters, new InputSource(myOwnInputStream)); concatenator.appendDocument(src); } The problem is that even on my 2-core laptop, I frequently get exceptions silently written in standard error. Different stacktraces are attached and as you can see happen when batik parses the SVG files. For the same input the strings read are corrupted. For example the overflow=visible is read as vssible and then later as vissibll. Also the fill=#EC2227 is try to parse E7E8 as color. The workaround for my application is to have a new instance of FopFactory per thread but I would like to fix it and create a patch. Since I am quite new to FOP, I would like some advise on what should be the proper level. The higher one would be the FopFactory (but it's too high and I could do it externally in my code), then there is the org.apache.xmlgraphics.image.loader.ImageManager and at the end we get to the very low level org.apache.batik.css.engine.CSSEngine or org.apache.batik.css.parser.Parser. Secondly, I think it's not a good
Is org.apache.fop.apps.FopFactory thread safe ?
Hello, The javadoc and the class name suggest that FopFactory should be thread-safe although this is not explicitly written. If this is not thread-safe then please ignore what follows. I am using FOP 1.0 to produce PDF documents concurrently from FOP intermediate format. The PDF documents share a lot of common images, so I decided to use a single instance of FopFactory to reduce memory requirements. From the single FopFactory, I produce different instances for different threads like this: FOUserAgent userAgent = fopFactory.newFOUserAgent(); IFDocumentHandler targetHandler = fopFactory.getRendererFactory().createDocumentHandler(userAgent,outputFormat); IFUtil.setupFonts(targetHandler); targetHandler.setResult(new StreamResult(outStream)); IFConcatenator concatenator = new IFConcatenator(targetHandler, null); for (int i = 0; i numberOfDocumentsToConcatenate; i++) { Source src = new SAXSource(myOwnApplicationXmlFilters, new InputSource(myOwnInputStream)); concatenator.appendDocument(src); } The problem is that even on my 2-core laptop, I frequently get exceptions silently written in standard error. Different stacktraces are attached and as you can see happen when batik parses the SVG files. For the same input the strings read are corrupted. For example the overflow=visible is read as vssible and then later as vissibll. Also the fill=#EC2227 is try to parse E7E8 as color. The workaround for my application is to have a new instance of FopFactory per thread but I would like to fix it and create a patch. Since I am quite new to FOP, I would like some advise on what should be the proper level. The higher one would be the FopFactory (but it's too high and I could do it externally in my code), then there is the org.apache.xmlgraphics.image.loader.ImageManager and at the end we get to the very low level org.apache.batik.css.engine.CSSEngine or org.apache.batik.css.parser.Parser. Secondly, I think it's not a good practice that the exceptions are written in STDERR instead of propagating to the application. What do you think ? This is my first post to fop-dev and hopefully this is the proper one. Thanks, Alexis STACKTRACE 1: (In [] it's the thred name) 00:13:22,819 [idocsWorker-8] INFO [TaskExecutor] Registered worker ConcatBill2_1 class=com.idocs.export2.ConcatWorker hash=568585021 [26ms] 00:13:22,822 [idocsWorker-7] INFO [TaskExecutor] Registered worker ConcatBill2_2 class=com.idocs.export2.ConcatWorker hash=2121659584 [30ms] 00:13:33,619 [idocsWorker-7_16.3.2] ERROR [STDERR] * CSSEngine: exception property.syntax.error:org.w3c.css.sac.CSSParseException: Invalid number. 00:13:33,619 [idocsWorker-7_16.3.2] ERROR [STDERR] AttrValue:new 0 0 25.896 51.791 00:13:33,619 [idocsWorker-7_16.3.2] ERROR [STDERR] Exception:org.w3c.css.sac.CSSParseException 00:13:33,619 [idocsWorker-7_16.3.2] ERROR [STDERR] org.w3c.css.sac.CSSParseException: Invalid number. 00:13:33,620 [idocsWorker-7_16.3.2] ERROR [STDERR] at org.apache.batik.css.parser.Parser.createCSSParseException(Unknown Source) 00:13:33,620 [idocsWorker-7_16.3.2] ERROR [STDERR] at org.apache.batik.css.parser.Parser.createCSSParseException(Unknown Source) 00:13:33,620 [idocsWorker-7_16.3.2] ERROR [STDERR] at org.apache.batik.css.parser.Parser.number(Unknown Source) 00:13:33,620 [idocsWorker-7_16.3.2] ERROR [STDERR] at org.apache.batik.css.parser.Parser.parseTerm(Unknown Source) 00:13:33,620 [idocsWorker-7_16.3.2] ERROR [STDERR] at org.apache.batik.css.parser.Parser.parseExpression(Unknown Source) 00:13:33,620 [idocsWorker-7_16.3.2] ERROR [STDERR] at org.apache.batik.css.parser.Parser.parsePropertyValueInternal(Unknown Source) 00:13:33,620 [idocsWorker-7_16.3.2] ERROR [STDERR] at org.apache.batik.css.parser.Parser.parsePropertyValue(Unknown Source) 00:13:33,620 [idocsWorker-7_16.3.2] ERROR [STDERR] at org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap(Unknown Source) 00:13:33,620 [idocsWorker-7_16.3.2] ERROR [STDERR] at org.apache.batik.css.engine.CSSEngine.getComputedStyle(Unknown Source) 00:13:33,620 [idocsWorker-7_16.3.2] ERROR [STDERR] at org.apache.batik.bridge.CSSUtilities.getComputedStyle(Unknown Source) 00:13:33,620 [idocsWorker-7_16.3.2] ERROR [STDERR] at org.apache.batik.bridge.CSSUtilities.convertVisibility(Unknown Source) 00:13:33,620 [idocsWorker-7_16.3.2] ERROR [STDERR] at org.apache.batik.bridge.SVGSVGElementBridge.createGraphicsNode(Unknown Source) 00:13:33,620 [idocsWorker-7_16.3.2] ERROR [STDERR] at org.apache.batik.bridge.GVTBuilder.build(Unknown Source) 00:13:33,620 [idocsWorker-7_16.3.2] ERROR [STDERR] at org.apache.fop.render.pdf.PDFImageHandlerSVG.handleImage(PDFImageHandlerSVG.java:93) 00:13:33,621 [idocsWorker-7_16.3.2] ERROR [STDERR] at org.apache.fop.render.intermediate.AbstractIFPainter.drawImage(AbstractIFPainter.java:227) 00:13:33,621 [idocsWorker-7_16.3.2] ERROR [STDERR] at
Re: Is org.apache.fop.apps.FopFactory thread safe ?
Alexis, This reminds me of something similar I ran into a while ago. I can't remember the details nor how I eventually got around this and/or whether you run into the same but the (weird) behavior you describe does look very similar. See http://old.nabble.com/Batik-exception-when-using-fop-with-svg-images-in-threaded-environment-td20809049.html Perhaps it helps Peter On 01 Sep 2010, at 17:53, Alexios Giotis wrote: Hello, The javadoc and the class name suggest that FopFactory should be thread-safe although this is not explicitly written. If this is not thread-safe then please ignore what follows. I am using FOP 1.0 to produce PDF documents concurrently from FOP intermediate format. The PDF documents share a lot of common images, so I decided to use a single instance of FopFactory to reduce memory requirements. From the single FopFactory, I produce different instances for different threads like this: FOUserAgent userAgent = fopFactory.newFOUserAgent(); IFDocumentHandler targetHandler = fopFactory.getRendererFactory().createDocumentHandler(userAgent,outputFormat); IFUtil.setupFonts(targetHandler); targetHandler.setResult(new StreamResult(outStream)); IFConcatenator concatenator = new IFConcatenator(targetHandler, null); for (int i = 0; i numberOfDocumentsToConcatenate; i++) { Source src = new SAXSource(myOwnApplicationXmlFilters, new InputSource(myOwnInputStream)); concatenator.appendDocument(src); } The problem is that even on my 2-core laptop, I frequently get exceptions silently written in standard error. Different stacktraces are attached and as you can see happen when batik parses the SVG files. For the same input the strings read are corrupted. For example the overflow=visible is read as vssible and then later as vissibll. Also the fill=#EC2227 is try to parse E7E8 as color. The workaround for my application is to have a new instance of FopFactory per thread but I would like to fix it and create a patch. Since I am quite new to FOP, I would like some advise on what should be the proper level. The higher one would be the FopFactory (but it's too high and I could do it externally in my code), then there is the org.apache.xmlgraphics.image.loader.ImageManager and at the end we get to the very low level org.apache.batik.css.engine.CSSEngine or org.apache.batik.css.parser.Parser. Secondly, I think it's not a good practice that the exceptions are written in STDERR instead of propagating to the application. What do you think ? This is my first post to fop-dev and hopefully this is the proper one. Thanks, Alexis stacktraces.txt