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]
