Re: FOP 0.93: Java Heap Space OutOfMemory
On Jul 11, 2007, at 08:21, Daniel Noll wrote: Hi Daniel On Tuesday 10 July 2007 02:32:30 Andreas L Delmelle wrote: Not really. It's a matter of using common sense, I guess... Putting all content together inside one and the same page-sequence is bound to get you in trouble. Is there an alternative for situations where the content comes from elsewhere? Problem is it's not trivial to determine where to break the page sequence. If it breaks in the middle of a page, then you end up with half a page of fail. I know... The source XML has to have some logical boundaries/groups at which you can start a new page-sequence, otherwise this tip is useless. Currently there is no alternative, I'm afraid (unless you consider / not/ using FOP an option...) Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.93: Java Heap Space OutOfMemory
We also have a memory issue due to very large page sequences. One thing we do is offer the customer two report outputs: PDF and something called PDF Simple. PDF is the regular report that has a single page sequence and can consume a lot of memory. The simple output is the same report, but we break the page sequences every n number if lines. It does result in some half populated pages, but the memory and speed improvement make it worth it to our customers. -Lou Andreas L Delmelle [EMAIL PROTECTED] wrote on 07/11/2007 01:09:29 PM: On Jul 11, 2007, at 08:21, Daniel Noll wrote: Hi Daniel On Tuesday 10 July 2007 02:32:30 Andreas L Delmelle wrote: Not really. It's a matter of using common sense, I guess... Putting all content together inside one and the same page-sequence is bound to get you in trouble. Is there an alternative for situations where the content comes from elsewhere? Problem is it's not trivial to determine where to break the page sequence. If it breaks in the middle of a page, then you end up with half a page of fail. I know... The source XML has to have some logical boundaries/groups at which you can start a new page-sequence, otherwise this tip is useless. Currently there is no alternative, I'm afraid (unless you consider / not/ using FOP an option...) Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.93: Java Heap Space OutOfMemory
On Jul 11, 2007, at 20:12, [EMAIL PROTECTED] wrote: Hi Lou We also have a memory issue due to very large page sequences. One thing we do is offer the customer two report outputs: PDF and something called PDF Simple. PDF is the regular report that has a single page sequence and can consume a lot of memory. The simple output is the same report, but we break the page sequences every n number if lines. It does result in some half populated pages, but the memory and speed improvement make it worth it to our customers. Just curious: how exactly do you break the page-sequences? I've seen it done in some Bugzilla, IIC, but I cannot remember the details. All I remember is that it was a very dirty hack... In the end, that page-sequence boundary is currently not a major issue if you take into account: a) what you get in return (absolutely gratis) b) how easy it is sometimes to sell the dirty solution as a necessary evil (especially when it means it will cost the customer less) c) that no one ever really sees much more of these 1000-paged reports than the first 20 pages anyway :) FYI: Note that a similar limit also applies to blocks, although people tend to run into this far less often. In case of very large page- sequences, those generally never make it to the layout stage. The heap will be filled with the page-sequence and all its descendants. A huge block of text OTOH still occupies relatively little space in terms of memory, but it's only when layout begins that the memory usage increases drastically and FOP finally dies because of the ridiculous amount of break-possibilities the layout algorithm is forced to consider. Give it a few forced breaks and everything runs smoothly. That said, we'd definitely appreciate any suggestions in terms of architectural changes to shift this logic of forcing breaks into FOP's black box. Something like an internal threshold, in terms of memory consumption, number of Java object instances or the amount of break-possibilities? Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.93: Java Heap Space OutOfMemory
An interesting bit of synchronicity, Lou - one of my clients does the same thing. For every client who wants the whole thing, I think there's about three who use the simple format. Both use FOP to produce a PDF, but the results and processing times are very different. Often, negotiating with your end users (explaining the situation and offering some choices) both gets one out of a tough box and gives the users some choices they like. FWIW Jay Bryant Bryant Communication Services - Original Message - From: [EMAIL PROTECTED] To: fop-users@xmlgraphics.apache.org Sent: Wednesday, July 11, 2007 1:12 PM Subject: Re: FOP 0.93: Java Heap Space OutOfMemory We also have a memory issue due to very large page sequences. One thing we do is offer the customer two report outputs: PDF and something called PDF Simple. PDF is the regular report that has a single page sequence and can consume a lot of memory. The simple output is the same report, but we break the page sequences every n number if lines. It does result in some half populated pages, but the memory and speed improvement make it worth it to our customers. -Lou Andreas L Delmelle [EMAIL PROTECTED] wrote on 07/11/2007 01:09:29 PM: On Jul 11, 2007, at 08:21, Daniel Noll wrote: Hi Daniel On Tuesday 10 July 2007 02:32:30 Andreas L Delmelle wrote: Not really. It's a matter of using common sense, I guess... Putting all content together inside one and the same page-sequence is bound to get you in trouble. Is there an alternative for situations where the content comes from elsewhere? Problem is it's not trivial to determine where to break the page sequence. If it breaks in the middle of a page, then you end up with half a page of fail. I know... The source XML has to have some logical boundaries/groups at which you can start a new page-sequence, otherwise this tip is useless. Currently there is no alternative, I'm afraid (unless you consider / not/ using FOP an option...) Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.93: Java Heap Space OutOfMemory
Andreas: I have several _wonderful_ users that demand to generate several thousand page reports and kill many, many trees, all in the name of something. I should just render the first and last 20 pages and fill the middle 1960 pages with blanks - I bet they never notice. :) With that said, this is how I break the page sequences: xsl:for-each select=reportrow[position() mod $rowCount = 1] fo:page-sequence master-reference=generic language=en country=us fo:static-content flow-name=xsl-region-before snip/ /fo:static-content fo:static-content flow-name=xsl-region-after snip/ /fo:static-content fo:flow flow-name=xsl-region-body fo:table table-layout=fixed width=100% xsl:for-each select=columns/column fo:table-column snip/ /fo:table-column /xsl:for-each fo:table-header snip/ /fo:table-header fo:table-body xsl:for-each select=.|following-sibling::reportrow[position() lt; $rowCount] fo:table-row snip/ /fo:table-row /xsl:for-each /fo:table-body /fo:table /fo:flow /fo:page-sequence /xsl:for-each I did not know that block could also consume a lot of memory - it gives me something else to check - thanks. -Lou Andreas L Delmelle [EMAIL PROTECTED] wrote on 07/11/2007 02:51:45 PM: On Jul 11, 2007, at 20:12, [EMAIL PROTECTED] wrote: Hi Lou We also have a memory issue due to very large page sequences. One thing we do is offer the customer two report outputs: PDF and something called PDF Simple. PDF is the regular report that has a single page sequence and can consume a lot of memory. The simple output is the same report, but we break the page sequences every n number if lines. It does result in some half populated pages, but the memory and speed improvement make it worth it to our customers. Just curious: how exactly do you break the page-sequences? I've seen it done in some Bugzilla, IIC, but I cannot remember the details. All I remember is that it was a very dirty hack... In the end, that page-sequence boundary is currently not a major issue if you take into account: a) what you get in return (absolutely gratis) b) how easy it is sometimes to sell the dirty solution as a necessary evil (especially when it means it will cost the customer less) c) that no one ever really sees much more of these 1000-paged reports than the first 20 pages anyway :) FYI: Note that a similar limit also applies to blocks, although people tend to run into this far less often. In case of very large page- sequences, those generally never make it to the layout stage. The heap will be filled with the page-sequence and all its descendants. A huge block of text OTOH still occupies relatively little space in terms of memory, but it's only when layout begins that the memory usage increases drastically and FOP finally dies because of the ridiculous amount of break-possibilities the layout algorithm is forced to consider. Give it a few forced breaks and everything runs smoothly. That said, we'd definitely appreciate any suggestions in terms of architectural changes to shift this logic of forcing breaks into FOP's black box. Something like an internal threshold, in terms of memory consumption, number of Java object instances or the amount of break-possibilities? Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FOP 0.93: Java Heap Space OutOfMemory
Seems there was not enough space on harddisk for generating the PDF-Output with FOP 0.93. Is there a option for FOP to display how many space on harddisk is needed while generating a PDF? This time over 200 MB were needed by FOP to generate a less than 2 MB big PDF-File. Regards, Kerstin --- [EMAIL PROTECTED] schrieb: While generating a PDF from XML+XSL using FOP 0.93, FOP stops with Exception in thread main java.lang.OutOfMemoryError: Java heap space. Are their any limitations set in FOP or this is just a problem of to few system memory? The generated PDF have more than 71 pages. - Besseren Schutz gegen Spam - jetzt bei dem neuen Yahoo! Mail . __ Die besten Tipps und Tricks fürs Grillen. BE A BETTER GRILLMEISTER! www.yahoo.de/clever - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.93: Java Heap Space OutOfMemory
On Jul 9, 2007, at 09:30, [EMAIL PROTECTED] leeloo5e79- [EMAIL PROTECTED] wrote: Hi Seems there was not enough space on harddisk for generating the PDF-Output with FOP 0.93. Not enough disk space? So your JVM wanted to swap but couldn't? Is there a option for FOP to display how many space on harddisk is needed while generating a PDF? Not really. It's a matter of using common sense, I guess... Putting all content together inside one and the same page-sequence is bound to get you in trouble. I managed to let FOP die with an OOM once, for a document that contained a little over 40 pages... On the other hand, some users have reported generating documents of +1 pages without any particular problem. FWIW: the current trunk version already contains some optimizations in terms of memory usage. If you're at liberty to try it out, and see if it helps you... All feedback is welcome. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.93: Java Heap Space OutOfMemory
Try increasing the amount of memory available to your VM by using the
java extended argument option -Xmx{???}M, where {???} is the number of
megabytes you wish to make available to the java virtual machine.
Adrian.
[EMAIL PROTECTED] wrote:
While generating a PDF from XML+XSL using FOP 0.93, FOP stops with
Exception in thread main java.lang.OutOfMemoryError: Java heap
space. Are their any limitations set in FOP or this is just a problem
of to few system memory?
The generated PDF have more than 71 pages.
Besseren Schutz gegen Spam - jetzt bei dem neuen Yahoo! Mail
http://de.rd.yahoo.com/evt=40589/*http://de.docs.yahoo.com/ymail/landing.html
.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.93: Java Heap Space OutOfMemory
On Jul 2, 2007, at 17:12, [EMAIL PROTECTED] leeloo5e79- [EMAIL PROTECTED] wrote: Hi, While generating a PDF from XML+XSL using FOP 0.93, FOP stops with Exception in thread main java.lang.OutOfMemoryError: Java heap space. Are their any limitations set in FOP or this is just a problem of to few system memory? The generated PDF have more than 71 pages. Apart from what Adrian already replied (increase JVM max. heap space), it could also help, if possible for you of course, to structure the FO differently. There are no absolute limits set in FOP, but there are limits that follow from the current architecture. A document containing 1000 page- sequences of 10 pages without forward references should be processed w/o problems. A document containing 1 page-sequence of 50 pages may already be enough for FOP to run out of memory... Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
