RE: Java Heap
You can't generate big files, or you need more memory. More memory could be referring to either your physical system memory or your allocated Java memory. This should have norhing to do with your line overflows. Make text smaller or blocks bigger. In my usage, I just put a condition that would tell the user don't do that if they try to print a report over like 1000 pages. I'm not sure where the memory cutoff would be, but they should normally never need giant reports. A report that big typically means they need to enter more criteria to limit results. I'm sure there's a workaround to print giant reports if there is a need. Maybe you could try creating multiple PDFs and combining? Maybe there's a fix in the Trunk? I haven't bothered to figure out how because it's easier to say don't do that. To figure out why you're overflowing, someone would most likely need to see your actual XML/XSL/FO code. I have mine dynamically setting the font size and block size to make sure it fits. From: Andrey Skrypnik [mailto:askryp...@meritservus.com] Sent: Wednesday, June 09, 2010 10:57 AM To: fop-users@xmlgraphics.apache.org Subject: Java Heap Hi guys, I'm using FOP 0.95 i when i try to generate a big file i received: SEVERE: Servlet.service() for servlet meritservus threw exception java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOfRange(Arrays.java:3209) at java.lang.String.init(String.java:215) at java.lang.StringBuffer.toString(StringBuffer.java:585) at java.io.StringWriter.toString(StringWriter.java:193) but before i have a huge amount of rows: WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm: 388 - Line 1 of a paragraph overflows the available area by 3226mpt. (fo:block, LVBND_2624500) 17:16:06.688 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm: 388 - Line 1 of a paragraph overflows the available area by 3226mpt. (fo:block, LVBND_2624500) 17:16:06.688 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm: 388 - Line 1 of a paragraph overflows the available area by 3226mpt. (fo:block, LVBND_2624500) 17:16:06.813 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm: 388 - Line 1 of a paragraph overflows the available area by 12906mpt. (fo:block, COMMUNICATIONS) 17:16:09.985 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm: 388 - Line 1 of a paragraph overflows the available area by 12906mpt. (fo:block, COMMUNICATIONS) 17:16:10.423 WARN [http-8080-3] org.apache.fop.layoutmgr.inline.LineLayoutManager$LineBreakingAlgorithm: 388 - Line 1 of a paragraph overflows the available area by 14890mpt. (fo:block, SAMPLE_PORT_USD) Please, help me, how I can fix it! Thanks a lot! __ Information from ESET NOD32 Antivirus, version of virus signature database 5184 (20100609) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
Re: Java Heap
On 09.06.2010 16:57, Andrey Skrypnik wrote: I'm using FOP 0.95 i when i try to generate a big file i received: SEVERE: Servlet.service() for servlet meritservus threw exception java.lang.OutOfMemoryError: Java heap space See http://xmlgraphics.apache.org/fop/0.95/running.html#memory J.Pietschmann - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Java heap overflow error - unknown reason
We have this environment setting: set FOP_OPTS=-Xmx999m %FOP_OPTS% Then we run the fop command line. To post the fo file I will need to replace the text with gibberish since it is sensitive material. I will attempt to upload it later today. David Kelly Jeremias Maerki-2 wrote: Are you actually giving FOP a little memory to play with? I mean a little more than the 64MB allocated by default? FOP is still a bit memory-intensive, but 100 pages (per page-sequence) should easily be handled with less than 512MB. If you can, post a link to an FO file. That would allow us to do some profiling to see why this happens (if my very obvious tip above doesn't apply). Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Java-heap-overflow-error---unknown-reason-tp18929472p18961914.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java heap overflow error - unknown reason
Hmm - I see now that although the environment variable I mentioned earlier had been set, that variable was not placed on the fop command line. I have corrected the problem and it now runs fine. My apologies for the misdirection, and thank you for the hint. Regards, David Kelly Are you actually giving FOP a little memory to play with? I mean a little more than the 64MB allocated by default? FOP is still a bit memory-intensive, but 100 pages (per page-sequence) should easily be handled with less than 512MB. If you can, post a link to an FO file. That would allow us to do some profiling to see why this happens (if my very obvious tip above doesn't apply). -- View this message in context: http://www.nabble.com/Java-heap-overflow-error---unknown-reason-tp18929472p18962257.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java heap overflow error - unknown reason
Nevertheless, if you can post the fo with gibberish it would be useful for profiling purposes... (if sensitive, send it directly to the dev team and not to the list). There is always a lack of real world examples! And real world is always giving us surprises. ;) On Wed, Aug 13, 2008 at 1:40 PM, DavidJKelly [EMAIL PROTECTED] wrote: Hmm - I see now that although the environment variable I mentioned earlier had been set, that variable was not placed on the fop command line. I have corrected the problem and it now runs fine. My apologies for the misdirection, and thank you for the hint. Regards, David Kelly Are you actually giving FOP a little memory to play with? I mean a little more than the 64MB allocated by default? FOP is still a bit memory-intensive, but 100 pages (per page-sequence) should easily be handled with less than 512MB. If you can, post a link to an FO file. That would allow us to do some profiling to see why this happens (if my very obvious tip above doesn't apply). -- View this message in context: http://www.nabble.com/Java-heap-overflow-error---unknown-reason-tp18929472p18962257.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java heap overflow error - unknown reason
Andreas, Most of the book was in fact in a single page sequence. I attempted the three fixes you suggested, but with no luck. The FO is now in page sequences less than 100 pages each, and all fo:inlines are now fo:wrappers. I have also removed all keep-together and keep-with attributes. At risk of repetition, here is the error I get: WARNING: Line 2 of a paragraph overflows the available area by 400mpt. (fo:block , location: 46211/114) Exception in thread main java.lang.OutOfMemoryError: Java heap space at org.apache.fop.layoutmgr.inline.TextLayoutManager.createTextArea(Text LayoutManager.java:408) at org.apache.fop.layoutmgr.inline.TextLayoutManager.addAreas(TextLayout Manager.java:361) at org.apache.fop.layoutmgr.inline.LineLayoutManager.addInlineArea(LineL ayoutManager.java:1716) at org.apache.fop.layoutmgr.inline.LineLayoutManager.addAreas(LineLayout Manager.java:1568) at org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag er.java:395) at org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag er.java:395) at org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag er.java:395) at org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag er.java:395) at org.apache.fop.layoutmgr.AreaAdditionUtil.addAreas(AreaAdditionUtil.j ava:121) at org.apache.fop.layoutmgr.FlowLayoutManager.addAreas(FlowLayoutManager .java:305) at org.apache.fop.layoutmgr.PageBreaker.addAreas(PageBreaker.java:241) at org.apache.fop.layoutmgr.AbstractBreaker.addAreas(AbstractBreaker.jav a:508) at org.apache.fop.layoutmgr.AbstractBreaker.addAreas(AbstractBreaker.jav a:371) at org.apache.fop.layoutmgr.PageBreaker.doPhase3(PageBreaker.java:262) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.jav a:346) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.jav a:264) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(Pag eSequenceLayoutManager.java:106) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.j ava:234) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java :123) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilde r.java:340) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:169) at org.apache.xalan.transformer.TransformerIdentityImpl.endElement(Trans formerIdentityImpl.java:1101) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source ) at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknow n Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent Dispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Un known Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Sour ce) Many thanks for the quickness of your previous reply. Any further help you might be able to offer would be appreciated. Regards, David Kelly Andreas Delmelle-2 wrote: On Aug 11, 2008, at 18:43, DavidJKelly wrote: Hi I have been trying to troubleshoot a java heap error for a good while, and I have researched the error messages on this site without luck. I have a 6000+ page document with numerous tables - the largest tables being at the front of the document, where they run fine. In dividing the document, I find that it gets to slightly over 3000 pages before it dies. Because the tables are simple two-column tables, I tried setting them up as lists in list-blocks, but I still get a similar error. Following are the errors from both the table and list versions: It depends on how large the individual page-sequences are. If you cram all 6000 pages into one page-sequence, and do not use forced breaks anywhere, you're going to need what looks like an unreasonable amount of heap to render the document (because the current implementation of the layout algorithm does not consider any page- break final, unless in case of a forced break, or the end of the page- sequence). If possible, try to break up the document into multiple page- sequences, and the issue should disappear. Other hint: if the document contains a lot of fo:inlines, try simply replacing those with fo:wrapper. Cheers Andreas - To unsubscribe,
Re: Java heap overflow error - unknown reason
Are you actually giving FOP a little memory to play with? I mean a little more than the 64MB allocated by default? FOP is still a bit memory-intensive, but 100 pages (per page-sequence) should easily be handled with less than 512MB. If you can, post a link to an FO file. That would allow us to do some profiling to see why this happens (if my very obvious tip above doesn't apply). On 12.08.2008 21:53:25 DavidJKelly wrote: Andreas, Most of the book was in fact in a single page sequence. I attempted the three fixes you suggested, but with no luck. The FO is now in page sequences less than 100 pages each, and all fo:inlines are now fo:wrappers. I have also removed all keep-together and keep-with attributes. At risk of repetition, here is the error I get: WARNING: Line 2 of a paragraph overflows the available area by 400mpt. (fo:block , location: 46211/114) Exception in thread main java.lang.OutOfMemoryError: Java heap space at org.apache.fop.layoutmgr.inline.TextLayoutManager.createTextArea(Text LayoutManager.java:408) at org.apache.fop.layoutmgr.inline.TextLayoutManager.addAreas(TextLayout Manager.java:361) at org.apache.fop.layoutmgr.inline.LineLayoutManager.addInlineArea(LineL ayoutManager.java:1716) at org.apache.fop.layoutmgr.inline.LineLayoutManager.addAreas(LineLayout Manager.java:1568) at org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag er.java:395) at org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag er.java:395) at org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag er.java:395) at org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManag er.java:395) at org.apache.fop.layoutmgr.AreaAdditionUtil.addAreas(AreaAdditionUtil.j ava:121) at org.apache.fop.layoutmgr.FlowLayoutManager.addAreas(FlowLayoutManager .java:305) at org.apache.fop.layoutmgr.PageBreaker.addAreas(PageBreaker.java:241) at org.apache.fop.layoutmgr.AbstractBreaker.addAreas(AbstractBreaker.jav a:508) at org.apache.fop.layoutmgr.AbstractBreaker.addAreas(AbstractBreaker.jav a:371) at org.apache.fop.layoutmgr.PageBreaker.doPhase3(PageBreaker.java:262) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.jav a:346) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.jav a:264) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(Pag eSequenceLayoutManager.java:106) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.j ava:234) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java :123) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilde r.java:340) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:169) at org.apache.xalan.transformer.TransformerIdentityImpl.endElement(Trans formerIdentityImpl.java:1101) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source ) at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknow n Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContent Dispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Un known Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Sour ce) Many thanks for the quickness of your previous reply. Any further help you might be able to offer would be appreciated. Regards, David Kelly Andreas Delmelle-2 wrote: On Aug 11, 2008, at 18:43, DavidJKelly wrote: Hi I have been trying to troubleshoot a java heap error for a good while, and I have researched the error messages on this site without luck. I have a 6000+ page document with numerous tables - the largest tables being at the front of the document, where they run fine. In dividing the document, I find that it gets to slightly over 3000 pages before it dies. Because the tables are simple two-column tables, I tried setting them up as lists in list-blocks, but I still get a similar error. Following are the errors from both the table and list versions: It depends on how large the individual page-sequences are. If you cram all 6000 pages into one page-sequence, and do not use forced breaks anywhere, you're going to need what looks like an
Re: Java heap overflow error - unknown reason
On Aug 11, 2008, at 18:43, DavidJKelly wrote: Hi I have been trying to troubleshoot a java heap error for a good while, and I have researched the error messages on this site without luck. I have a 6000+ page document with numerous tables - the largest tables being at the front of the document, where they run fine. In dividing the document, I find that it gets to slightly over 3000 pages before it dies. Because the tables are simple two-column tables, I tried setting them up as lists in list-blocks, but I still get a similar error. Following are the errors from both the table and list versions: It depends on how large the individual page-sequences are. If you cram all 6000 pages into one page-sequence, and do not use forced breaks anywhere, you're going to need what looks like an unreasonable amount of heap to render the document (because the current implementation of the layout algorithm does not consider any page- break final, unless in case of a forced break, or the end of the page- sequence). If possible, try to break up the document into multiple page- sequences, and the issue should disappear. Other hint: if the document contains a lot of fo:inlines, try simply replacing those with fo:wrapper. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
