Re: Thread safe?
On 30 Mar 2011, at 15:36, Eric Douglas wrote: Hi Eric I am talking about the first. Basically, it is a completely separate XSLT/JAXP implementation (TransformerFactory, Transformer etc.) Since you mentioned that the issue manifests itself only when using Oracle's Transformer implementation, a possible workaround/solution may be to use a different implementation. Note that Oracle's XML parser and XSLT processors are no strangers on this list, when it comes to weird, inexplicable bugs. Usually, the problem goes away if people switch to the latest Xerces in combination with Xalan or Saxon... Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: Thread safe?
What Saxon are you talking about? The Saxon project (http://saxon.sourceforge.net/)? The Oracle sax (http://download.oracle.com/javase/6/docs/api/javax/xml/transform/sax/SA XTransformerFactory.html)? Would a Transformer work any better if it's created from the sax factory rather than the TransformerFactory? Transformer = javax.xml.transform.TransformerFactory.newTransformer() Vs Transformer = javax.xml.transform.sax.SAXTransformerFactory.newTransformerHandler().ge tTransformer() Somehow they both arrive at javax.xml.transform.Transformer. -Original Message- From: Andreas L. Delmelle [mailto:andreas.delme...@telenet.be] Sent: Tuesday, March 29, 2011 5:11 PM To: fop-users@xmlgraphics.apache.org Subject: Re: Thread safe? On 29 Mar 2011, at 22:55, Eric Douglas wrote: > I have yet to see any threading problems with the FOP objects. Well, there probably are /some/, but in general, care has been taken to make sure that each rendering-run is isolated, and the process itself is currently completely single-threaded (which does leave room for optimization on the one hand, extra debugging headaches on the other ;-)). Those parts that are meant to be shared among threads are usually properly synchronized, although glitches do pop up from time to time. Mostly in the Java2D/AWT area. Understandable, since the API docs do not mention anything about classes not being thread-safe, and often it concerns the real 'innards' of the JVM, and you'll find some sun.com classes in the stack trace, references to native methods, etc. Nothing we could have foreseen... > My error seems to be just on Oracle's Transformer. Ahaaa!!! Them again! :-) So, you're saying it doesn't happen with, say, Saxon? Regards, Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Thread safe?
On 29 Mar 2011, at 22:55, Eric Douglas wrote: > I have yet to see any threading problems with the FOP objects. Well, there probably are /some/, but in general, care has been taken to make sure that each rendering-run is isolated, and the process itself is currently completely single-threaded (which does leave room for optimization on the one hand, extra debugging headaches on the other ;-)). Those parts that are meant to be shared among threads are usually properly synchronized, although glitches do pop up from time to time. Mostly in the Java2D/AWT area. Understandable, since the API docs do not mention anything about classes not being thread-safe, and often it concerns the real 'innards' of the JVM, and you'll find some sun.com classes in the stack trace, references to native methods, etc. Nothing we could have foreseen... > My error seems to be just on Oracle's Transformer. Ahaaa!!! Them again! :-) So, you're saying it doesn't happen with, say, Saxon? Regards, Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: Thread safe?
Yeah, that means you should only have one per class which should work for multiple instances. The threading issue is what I'm looking at now, where I have multiple sessions running concurrently. I have yet to see any threading problems with the FOP objects. My error seems to be just on Oracle's Transformer. That page also mentions threading, at your own risk, though it was from 0.95 so I don't know if they've done much additional testing or changes since. "Multithreading FOP Apache FOP may currently not be completely thread safe. The code has not been fully tested for multi-threading issues, yet. If you encounter any suspicious behaviour, please notify us. There is also a known issue with fonts being jumbled between threads when using the Java2D/AWT renderer (which is used by the -awt and -print output options). In general, you cannot safely run multiple threads through the AWT renderer. " -Original Message- From: Terence M. Bandoian [mailto:tere...@tmbsw.com] Sent: Tuesday, March 29, 2011 6:01 PM To: fop-users@xmlgraphics.apache.org Subject: Re: Thread safe? Hi- Thanks. However, reusability doesn't necessarily mean thread-safe. -Terence Bandoian On 3/29/2011 2:15 PM, Eric Douglas wrote: > I would guess the answer is yes based on > http://xmlgraphics.apache.org/fop/0.95/embedding.html > > "// Reuse the FopFactory if possible!" > > -Original Message- > From: Terence M. Bandoian [mailto:tere...@tmbsw.com] > Sent: Tuesday, March 29, 2011 5:22 PM > To: fop-users@xmlgraphics.apache.org > Subject: Re: Thread safe? > >Hi- > > Is FopFactory thread-safe? > > -Terence Bandoian > > > On 3/29/2011 1:56 PM, Andreas L. Delmelle wrote: >> On 29 Mar 2011, at 21:23, Eric Douglas wrote: >> >>> It's actually crashing on the first transformer. It only crashes if >>> I run 2 of these at once. Is there something obvious I'm missing in >>> this java code? >> >> >> Perhaps... We do not see the declaration of 'myTransformer'. Is that > variable local to each thread? Transformers are definitely not > thread-safe, so should be separate instances for multiple concurrent > transformations. The TransformerFactory is thread-safe, so can be > shared without issues. >> >> Regards >> >> Andreas >> --- >> - >> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org >> For additional commands, e-mail: >> fop-users-h...@xmlgraphics.apache.org >> >> > - > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org > > > - > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org > > - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Thread safe?
Hi- Thanks. However, reusability doesn't necessarily mean thread-safe. -Terence Bandoian On 3/29/2011 2:15 PM, Eric Douglas wrote: I would guess the answer is yes based on http://xmlgraphics.apache.org/fop/0.95/embedding.html "// Reuse the FopFactory if possible!" -Original Message- From: Terence M. Bandoian [mailto:tere...@tmbsw.com] Sent: Tuesday, March 29, 2011 5:22 PM To: fop-users@xmlgraphics.apache.org Subject: Re: Thread safe? Hi- Is FopFactory thread-safe? -Terence Bandoian On 3/29/2011 1:56 PM, Andreas L. Delmelle wrote: On 29 Mar 2011, at 21:23, Eric Douglas wrote: It's actually crashing on the first transformer. It only crashes if I run 2 of these at once. Is there something obvious I'm missing in this java code? Perhaps... We do not see the declaration of 'myTransformer'. Is that variable local to each thread? Transformers are definitely not thread-safe, so should be separate instances for multiple concurrent transformations. The TransformerFactory is thread-safe, so can be shared without issues. Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: Thread safe?
I have 2 different stylesheets because I couldn't get one to pass in parameters to correctly print landscape. I'm not sure if I'll ever need more than 2 or if I want to hardcode them as the only 2. In this case the 2 sessions are reading the same file. The templates could prove useful, thanks, I'll check that out. I did add a test on my read to get the xsl file to ensure it read the entire file in so I don't think the stylesheet itself is actually the problem. I think the problem is the Transformer itself not being thread safe. I did try localizing the declare on the Transformers to the 3 methods which use them. That didn't help. If there's no concurrency option I'm missing to allow me to create the same sort of Transformer, running the same program in 2 sessions, the only other answer I can think of is to hack it. When I hit the statement my Transformer is crashing on, if it crashes, go back and recreate it. -Original Message- From: Andreas L. Delmelle [mailto:andreas.delme...@telenet.be] Sent: Tuesday, March 29, 2011 4:30 PM To: fop-users@xmlgraphics.apache.org Subject: Re: Thread safe? On 29 Mar 2011, at 22:13, Eric Douglas wrote: > I did include the new statement. The declaration is up at the class > level. There should be one factory for the class and one transformer > per instance. OK, that should be safe, indeed. > It's only when I run 2 at once the first transform crashes. That > error message sounds like there was an error reading in the xsl file > though the read statements didn't crash. Are both concurrent transformations trying to read the same XSL source file? As a crude attempt, perhaps you could try to synchronize the bare file access. I know some platforms have less of an issue with concurrent read-only access to files, but still... If that works and the use case allows it, there may be a more elegant/efficient solution, in the form of a call to TransformerFactory.newTemplates(). You can create one Templates instance for the same stylesheet, and instantiate multiple Transformers off of it. A Templates is also supposed to be thread-safe, so if you're always using the very same XSLT file, it can probably save you some overhead. Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Thread safe?
On 29 Mar 2011, at 22:13, Eric Douglas wrote: > I did include the new statement. The declaration is up at the class > level. There should be one factory for the class and one transformer > per instance. OK, that should be safe, indeed. > It's only when I run 2 at once the first transform > crashes. That error message sounds like there was an error reading in > the xsl file though the read statements didn't crash. Are both concurrent transformations trying to read the same XSL source file? As a crude attempt, perhaps you could try to synchronize the bare file access. I know some platforms have less of an issue with concurrent read-only access to files, but still... If that works and the use case allows it, there may be a more elegant/efficient solution, in the form of a call to TransformerFactory.newTemplates(). You can create one Templates instance for the same stylesheet, and instantiate multiple Transformers off of it. A Templates is also supposed to be thread-safe, so if you're always using the very same XSLT file, it can probably save you some overhead. Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: Thread safe?
I would guess the answer is yes based on http://xmlgraphics.apache.org/fop/0.95/embedding.html "// Reuse the FopFactory if possible!" -Original Message- From: Terence M. Bandoian [mailto:tere...@tmbsw.com] Sent: Tuesday, March 29, 2011 5:22 PM To: fop-users@xmlgraphics.apache.org Subject: Re: Thread safe? Hi- Is FopFactory thread-safe? -Terence Bandoian On 3/29/2011 1:56 PM, Andreas L. Delmelle wrote: > On 29 Mar 2011, at 21:23, Eric Douglas wrote: > >> It's actually crashing on the first transformer. It only crashes if >> I run 2 of these at once. Is there something obvious I'm missing in >> this java code? > > > Perhaps... We do not see the declaration of 'myTransformer'. Is that variable local to each thread? Transformers are definitely not thread-safe, so should be separate instances for multiple concurrent transformations. The TransformerFactory is thread-safe, so can be shared without issues. > > > Regards > > Andreas > --- > - > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org > > - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: Thread safe?
I did include the new statement. The declaration is up at the class level. There should be one factory for the class and one transformer per instance. This only crashes when I have 2 sessions running this same program at the same time. Each should have one instance of this class object. The variable statements look like this. private Transformer myTransformer; public static final TransformerFactory myTransformerFactory = TransformerFactory.newInstance(); It's reusing that Transformer variable within each method to create a new transformer object as needed. So we have the xsl Transformer in that method where I create the fo file. myTransformer = myTransformerFactory.newTransformer(myXslSS); And a plain transformer in the methods where it pulls in the fo handler with the different renderers to generate the output from the fo. myTransformer = myTransformerFactory.newTransformer(); That part works. It's only when I run 2 at once the first transform crashes. That error message sounds like there was an error reading in the xsl file though the read statements didn't crash. -Original Message- From: Andreas L. Delmelle [mailto:andreas.delme...@telenet.be] Sent: Tuesday, March 29, 2011 3:57 PM To: fop-users@xmlgraphics.apache.org Subject: Re: Thread safe? On 29 Mar 2011, at 21:23, Eric Douglas wrote: > It's actually crashing on the first transformer. It only crashes if I > run 2 of these at once. Is there something obvious I'm missing in > this java code? Perhaps... We do not see the declaration of 'myTransformer'. Is that variable local to each thread? Transformers are definitely not thread-safe, so should be separate instances for multiple concurrent transformations. The TransformerFactory is thread-safe, so can be shared without issues. Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Thread safe?
Hi- Is FopFactory thread-safe? -Terence Bandoian On 3/29/2011 1:56 PM, Andreas L. Delmelle wrote: On 29 Mar 2011, at 21:23, Eric Douglas wrote: It's actually crashing on the first transformer. It only crashes if I run 2 of these at once. Is there something obvious I'm missing in this java code? Perhaps... We do not see the declaration of 'myTransformer'. Is that variable local to each thread? Transformers are definitely not thread-safe, so should be separate instances for multiple concurrent transformations. The TransformerFactory is thread-safe, so can be shared without issues. Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Thread safe?
On 29 Mar 2011, at 21:23, Eric Douglas wrote: > It's actually crashing on the first transformer. It only crashes if I run 2 > of these at once. Is there something obvious I'm missing in this java > code? Perhaps... We do not see the declaration of 'myTransformer'. Is that variable local to each thread? Transformers are definitely not thread-safe, so should be separate instances for multiple concurrent transformations. The TransformerFactory is thread-safe, so can be shared without issues. Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: Thread safe?
Ok I crashed it again and checked the stack. This must be crashing on
the PDF rendering too. My test must not have run 2 of those at the same
time or close enough together. My PNG tests shouldn't be running at
exactly the same time but one must be close enough behind the other.
It actually crashes before it gets into the render. I am of course
using embedded code. I had it creating a transformer with an xsl file
and passing in the xml file as input and the fo handler as output to
render it all at once. I split that to pass an empty stream as output
so it creates an fo file then created a second transformer without the
xsl to pass that in with the fop handler to render the output. It's
actually crashing on the first transformer. It only crashes if I run 2
of these at once. Is there something obvious I'm missing in this java
code?
File myXslFile;
FileInputStream myXslFIS;
byte[] myXslSource;
ByteArrayInputStream myXslBAIS;
InputSource myXslIS;
myXslFile = new File(xslPath + xslFile);
myXslFIS = new FileInputStream(myXslFile);
myXslSource = new byte[myXslFIS.available()];
myXslFIS.read(myXslSource);
myXslFIS.close();
myXslBAIS = new ByteArrayInputStream(myXslSource);
myXslIS = new InputSource(myXslBAIS);
myXslSS = new SAXSource(myXslIS);
myFoByteArrayOutputStream = new ByteArrayOutputStream();
myStreamResult = new StreamResult(myFoByteArrayOutputStream);
myXmlSAXSource = createSAXSource(myXmlByteData);
myTransformer = myTransformerFactory.newTransformer(myXslSS);
myTransformer.setParameter("versionParam", "2.0");
myTransformer.transform(myXmlSAXSource,myStreamResult);
I get this error on the setParameter line.
[Fatal Error] :2:2: The markup in the document preceding the root
element must be well-formed.
SystemId Unknown; Line #2; Column #2; org.xml.sax.SAXParseException: The
markup in the document preceding the root element must be well-formed.
null
java.lang.NullPointerException
-Original Message-
From: Andreas L. Delmelle [mailto:andreas.delme...@telenet.be]
Sent: Tuesday, March 29, 2011 1:48 PM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Thread safe?
On 29 Mar 2011, at 17:29, Eric Douglas wrote:
Hi Eric
> I think this is what they mean by thread safe. I seem to have a
concurrency issue. If I call a transform using the Fop handler with a
PNGRenderer from 2 JVM sessions at or near the same time one crashes.
>
> I haven't been able to reproduce the problem so far with the
PDFRenderer so either it doesn't have the issue or my timing is off on
attempting to use it in 2 sessions at once.
The answer is that the PDFRenderer is entirely under our control --and
thus we are virtually certain it works well with concurrent runs--,
while the PNGRenderer (and also other formats, like TIFF) relies heavily
on Java2D and AWT. Those latter libraries are not thread-safe
themselves, and not always used in a thread-safe manner in XMLGraphics
and FOP...
Do you have a stack trace to go with the crash? If yes, do the processes
consistently fail on the same method call? If so, there is a chance that
we might be able to offer a fix in the short term.
Regards,
Andreas
---
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Thread safe?
On 29 Mar 2011, at 17:29, Eric Douglas wrote: Hi Eric > I think this is what they mean by thread safe. I seem to have a concurrency > issue. If I call a transform using the Fop handler with a PNGRenderer from 2 > JVM sessions at or near the same time one crashes. > > I haven't been able to reproduce the problem so far with the PDFRenderer so > either it doesn't have the issue or my timing is off on attempting to use it > in 2 sessions at once. The answer is that the PDFRenderer is entirely under our control --and thus we are virtually certain it works well with concurrent runs--, while the PNGRenderer (and also other formats, like TIFF) relies heavily on Java2D and AWT. Those latter libraries are not thread-safe themselves, and not always used in a thread-safe manner in XMLGraphics and FOP... Do you have a stack trace to go with the crash? If yes, do the processes consistently fail on the same method call? If so, there is a chance that we might be able to offer a fix in the short term. Regards, Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Thread safe?
I think this is what they mean by thread safe. I seem to have a concurrency issue. If I call a transform using the Fop handler with a PNGRenderer from 2 JVM sessions at or near the same time one crashes. I haven't been able to reproduce the problem so far with the PDFRenderer so either it doesn't have the issue or my timing is off on attempting to use it in 2 sessions at once.
