Memory Settings (was: java.lang.OutOfMemoryError)
The recent posts about FOP running out of memory has me thinking. Suppose for a second that FOP is run on a Windows 2000 box. Assume the box has 512 MB of RAM. Pretend that a certain XSL-FO causes the JVM to run out of memory. The question is: Can the JVM heap size be set to a value larger than the available RAM on the computer? For instance, in this case could -Xmx1024M be used to up the JVM heap to 1 GB? Would this prevent the JVM from crashing with an OutOfMemoryError? Now, *if* it did work, I'll assume that anytime an XSL-FO pushed the heap to a value higher than the amount of RAM, there would be a lot of memory swapping, which of course would hinder performance. But it might prevent a system crash. Would setting the JVM heap to a value higher than the available RAM adversely affect the performance of all XSL-FO's, or just the ones where the XSL-FO actually pushed the heap up that much in the first place? If anybody has tried this please share your experiences. Or, share your thoughts on what might happen. Thanks!! -Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Performance Question
I have FOP running on a Pentium 4 2.54 GHz computer with 1 GB memory and Win2000. I use Saxon 6.5.2 as the XML parser and XSLT engine. It also uses custom XMLReaders to produce SAX events which are processed by FOP. We usually see a PDF production rate of 8-9 pages per second, and we sometimes produce PDFs that are 1500+ pages. The only real problem with FOP is some of the XSL style sheet tricks necessary to insert intermittent page-sequences so FOP doesn't run out of memory. Hope this helps. Christian Neuroth To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: Subject: Performance Question 04/30/2003 03:30 AM Please respond to fop-user In my company, we are currently using StreamServe to produce documents (basically invoices). 50.000 docs/day, 3.000 prints, 47.000 pdf. The final document averages 3 pages (there are some exceptions with up to 1000 pages - very rare, however), a document containing only one graphic (logo). I am puzzling whether I can shift from StreamServer to FOP. Are there any people out there who apply FOP to achieve a similar volume? Is the performance ok? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Performance Question
We use XSLTC. I learned Java XML use and JAXP from an O'Reilly book entitled Java and XSLT by Eric Burke. It includes an example of a stylesheet cache that I found quite useful. Buy the book and check it out. Müller, Markus [EMAIL PROTECTED]To: [EMAIL PROTECTED] dm.de cc: Subject: AW: Performance Question 05/02/2003 11:23 AM Please respond to fop-user Hello Ryan, you're writing about a stylesheet-cache. How did you implement it? Do you use XSLTC or do you reuse the InputHandler object (according to the documentation, it can be reused). Markus $ -Ursprüngliche Nachricht- $ Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] $ Gesendet: Freitag, 2. Mai 2003 14:16 $ An: [EMAIL PROTECTED] $ Betreff: Re: Performance Question $ $ $ $ $ Sorry, I should have included these details also: $ $ Our PDFs are produced during a batch process, meaning the $ JVM is started $ once and all PDFs are then created. This, of course, means $ the JVM stays $ warm and we can take full advantage of HotSpot compilation. $ $ We also have implemented a style sheet cache, so once the $ style sheet has $ been used once the compiled version is reused over and over, which $ definitely helps performance. $ $ All of our XML/XSLT interfaces use JAXP, meaning we can plug $ in different $ XML/XSLT processors. We currently use Saxon 6.5.2 because it's the $ fastest, but it appears the recently-released Xalan 2.5 has $ closed the gap $ considerably. $ $ Even though the computer has 1 GB RAM available, we only $ allocate a max $ heap size of 512 MB. $ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Multithreading with FOP
I'm trying to use FOP 0.20.4 in a multi-threaded environment to produce PDFs. As I increase the number of threads from one or two to three or four, the average rendering time per PDF increases significantly. I realize that the host environment (available memory, number of processors, etc etc) can cause this affect, but I was wondering if there are any pitfalls, problems , or best practices with using FOP in a multi-threaded environment. Thanks!!! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Native compile using GCJ or Kaffe to boost performance
Try Excelsior's JET product, it might be more user friendly: http://www.excelsior-usa.com/home.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FOP on Mainframe
Hello, I'm trying to run FOP 0.20.4 on an IBM OS/390 mainframe, running under Unix System Services. I also use Saxon as the XML parser and XSL transformer. I get this error: Error at byte 3 of file:/u/tsryana/LMR/StandardRpts/xsl/StandardReportsPDF.xsl: Error reported by XML parser: invalid UTF-8 byte (check the XML declaration) ( code: 0xa7) I also tried Xerces and Xalan, and got this message fragment (the whole message is too long to cut and paste): ÝFatal Error¨ StandardReportsPDF.xsl:1:39: Content is not allowed in prolog. javax.xml.transform.TransformerConfigurationException: javax.xml.transform.Trans formerException: org.xml.sax.SAXParseException: Content is not allowed in prolog .. at org.apache.xalan.processor.TransformerFactoryImpl.newTemplates(Transf ormerFactoryImpl.java:995) at com.stpaul.xsl.StylesheetCache.getTemplates(StylesheetCache.java:79) at com.stpaul.pdf.PDFGenerator.renderPDF(PDFGenerator.java:72) at com.stpaul.totalclient.lmrstdrpts.control.StandardRptBatchController. renderPDF(StandardRptBatchController.java:448) at com.stpaul.totalclient.lmrstdrpts.control.StandardRptBatchController. createPdfForResult(StandardRptBatchController.java:95) at com.stpaul.totalclient.lmrstdrpts.control.StandardRptBatchController. run(StandardRptBatchController.java:504) at java.lang.Thread.run(Thread.java:512) - Here's the start of the XML declaration of the style sheet: ?xml version=1.0 encoding=UTF-8? So both XML/XSL parsers are complaining about style sheet. The run the same exact process on a Windows 2000 machine and it works flawlessly. I remember that when 0.20.4 came out, one of the changes was that it now works on EBCIDC machines. But, I still get this error. Does anybody know if this is an FOP problem or some sort of problem with the XML/XSL processors, or with the encoding of the style sheet on the mainframe? Ideas for fixes? Any help is appreciated. Thanks!! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP on Mainframe
I fixed the problem below. When FTP'ing the style sheets to the mainframe, I had to use binary mode instead of ascii. Thanks to everybody for the replies! [EMAIL PROTECTED] ul.com To: [EMAIL PROTECTED] cc: 11/22/2002 08:42 Subject: FOP on Mainframe AM Please respond to fop-user Hello, I'm trying to run FOP 0.20.4 on an IBM OS/390 mainframe, running under Unix System Services. I also use Saxon as the XML parser and XSL transformer. I get this error: Error at byte 3 of file:/u/tsryana/LMR/StandardRpts/xsl/StandardReportsPDF.xsl: Error reported by XML parser: invalid UTF-8 byte (check the XML declaration) ( code: 0xa7) I also tried Xerces and Xalan, and got this message fragment (the whole message is too long to cut and paste): ÝFatal Error¨ StandardReportsPDF.xsl:1:39: Content is not allowed in prolog. javax.xml.transform.TransformerConfigurationException: javax.xml.transform.Trans formerException: org.xml.sax.SAXParseException: Content is not allowed in prolog at org.apache.xalan.processor.TransformerFactoryImpl.newTemplates(Transf ormerFactoryImpl.java:995) at com.stpaul.xsl.StylesheetCache.getTemplates(StylesheetCache.java:79) at com.stpaul.pdf.PDFGenerator.renderPDF(PDFGenerator.java:72) at com.stpaul.totalclient.lmrstdrpts.control.StandardRptBatchController. renderPDF(StandardRptBatchController.java:448) at com.stpaul.totalclient.lmrstdrpts.control.StandardRptBatchController. createPdfForResult(StandardRptBatchController.java:95) at com.stpaul.totalclient.lmrstdrpts.control.StandardRptBatchController. run(StandardRptBatchController.java:504) at java.lang.Thread.run(Thread.java:512) - Here's the start of the XML declaration of the style sheet: ?xml version=1.0 encoding=UTF-8? So both XML/XSL parsers are complaining about style sheet. The run the same exact process on a Windows 2000 machine and it works flawlessly. I remember that when 0.20.4 came out, one of the changes was that it now works on EBCIDC machines. But, I still get this error. Does anybody know if this is an FOP problem or some sort of problem with the XML/XSL processors, or with the encoding of the style sheet on the mainframe? Ideas for fixes? Any help is appreciated. Thanks!! - 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]
