Jeremias, Thanx for your reply. I'll have to check with my boss on sharing the data as it's real world A/R data from one of our clients. (If I get a chance maybe I can scramble it thourhg a quick and dirty Groovy script.) As far as page breaks, adding page sequences was actually what I was referring to. I'll get back to you one sharing my report. Thanks again.
Cliff Jeremias Maerki-2 wrote: > > Any chance you can make this report available to us for testing (FO plus > resources)? > > Adding page breaks will not be enough, BTW. But you already noticed that. > FOP can currently only release memory at the end of a page-sequence. So > instead of creating page-breaks, try to restart a new page-sequence. The > memory usage should drop considerably. > > There's also a little class (CachedRenderPagesModel) which could > theoretically be used instead of the default RenderPagesModel. It allows > to temporarily off-load rendered pages to disk if they can't be rendered > right away. But this is not actively tested and does not help with the > memory consumption of the FO tree which probably is representing the > largest part in your case. > > On 05.01.2007 15:48:08 Cliff wrote: >> >> Hi Andreas, >> >> I remember you too. You helped me way back and I thank you. Yes, I'm in >> the >> throws of introducing more manual page breaks. I was just hoping, praying >> really, that something may have changed that would get me outta this hell >> I'm in. Doesn't look that way though. My current XSL was causing random >> overflow warnings on the console so I made some adjustments to get rid of >> them but the memory heap stayed the same when I re-ran it with jconsole >> monitoring. It's a 330+ page report and it causes the memory to shoot >> right >> up into the 500MB range which is completely unacceptable for a single >> report >> run by a single user. Maybe I can come up with something else clever in >> the >> interim. Thank you for all of your help. >> >> Cliff >> Hollaback... >> http://codeforfun.wordpress.com >> >> >> Andreas L Delmelle wrote: >> > >> > On Jan 4, 2007, at 21:34, Cliff wrote: >> > >> > Hi Cliff, >> > >> >> I'm facing FOP memory issues that I fought with a long time ago. I >> >> lost the >> >> battle back then and had to resort to some ugly manual page >> >> breaking logic >> >> and now I'm wondering the current status of the FOP project. >> >> My immediate question is: >> >> Do either FOP 0.20.5 or FOP Trunk address/improve on the memory issue >> >> regarding auto page breaks? >> > >> > I remember you... It was something like a second XSLT pass over the >> > FO input, right? >> > >> > Since that time, some memory leaks have been fixed, so it could >> > already help you. OTOH, the issue concerning large page-sequences has >> > not yet been addressed, unfortunately. >> > >> > Problem still remains at this point: FOP needs to build an internal >> > representation of the entire page-sequence before it can start any >> > formatting. (= due to the current architecture: the whole layout-loop >> > is triggered by AreaTreeHandler.endPageSequence()). >> > I've some ideas on how to improve the situation, but they're not >> > trivial adjustments, so I can't say when or even if these ideas will >> > make it into the codebase... >> > >> > >> > Cheers, >> > >> > Andreas >> > > > > > Jeremias Maerki > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/FOP-Memory-issues---please-help-tf2921893.html#a8179872 Sent from the FOP - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
