Dunno, Mat something else must be going on I can run it fine on my box. I noticed you are using the <fo:page-sequence master-reference="one"> tag . Did you upgrade to at least this version 0.20.4. I can runit fine with this version and above (see below the 2 ouputs). I can run it both embedded (0.20.4), and from the command line (0.20.5rc3).
result is attached Command Line: C:\fop>fop -d ReportOutput.fo report.pdf [DEBUG] Input mode: [DEBUG] FO ..... [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser [INFO] FOP 0.20.5rc3a [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser [INFO] building formatting object tree [INFO] setting up fonts [INFO] [1] [WARNING] table-layout=auto is not supported, using fixed! ... [WARNING] Sum of fixed column widths 521574 greater than maximum specified IPD 3 9685 [INFO] [2] .... [INFO] [6] [DEBUG] Last page-sequence produced 8 pages. [INFO] Parsing of document complete, stopping renderer [DEBUG] Initial heap size: 636Kb [DEBUG] Current heap size: 12794Kb [DEBUG] Total memory used: 12158Kb [DEBUG] Memory use is indicative; no GC was performed [DEBUG] These figures should not be used comparatively [DEBUG] Total time used: 4998ms [DEBUG] Pages rendered: 8 [DEBUG] Avg render time: 624ms/page Embedded: [ERROR] Logger not set [WARNING] Screen logger not set. [INFO] building formatting object tree [INFO] [1] [WARNING] table-layout=auto is not supported, using fixed! [WARNING] table-layout=auto is not supported, using fixed! [WARNING] table-layout=auto is not supported, using fixed! [WARNING] table-layout=auto is not supported, using fixed! [WARNING] Sum of fixed column widths 521574 greater than maximum specified IPD 39685 [INFO] [2] [INFO] [3] [INFO] [4] [INFO] [5] [INFO] [6] [INFO] [7] [INFO] [8] [INFO] Parsing of document complete, stopping renderer Rob. ----- Original Message ----- From: "Savino, Matt C" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, May 23, 2003 5:16 PM Subject: RE: Big/Huge XMLs Wow. Thanks for the extremely throrough investigation. This has me wondering if I use region-before for by column headers, could I just break the table every 100 rows or so? So I started working on it, but now I'm stumped. For some reason the attacehd FO, which looks fine to me is crashing not only FOP, but Weblogic entirely, with no warning at all. Can anyone see why? Very very strange. -Matt > -----Original Message----- > From: J.Pietschmann [mailto:[EMAIL PROTECTED] > Sent: Friday, May 23, 2003 11:43 AM > To: [EMAIL PROTECTED] > Subject: Re: Big/Huge XMLs > > > Savino, Matt C wrote: > > Below is the log output for a slightly larger (66 page) report... > > Reports are the root of all evil, oh well. > > Your small attachment expands to an impressive 4MB file, which > contains a single table with roughly 30'000 cells. It ultimately run > out of memory around page 4 on my JDK 1.3.1 -Xmx64M on WinNT. The FO > tree for the file soaks up a good chunk of the allocated memory, > according to Jochen Wiedmann's Dr.Mem memory profiler: > > bytes class > 4440832 org.apache.fop.fo.flow.Block > 4376280 org.apache.fop.fo.flow.TableCell > 3964032 org.apache.fop.fo.PropertyList > 2973024 org.apache.fop.fo.PropertyManager > 2355840 org.apache.fop.fo.FOText > 703200 org.apache.fop.fo.LengthProperty > 468640 org.apache.fop.datatypes.FixedLength > 163296 org.apache.fop.datatypes.KeepValue > 438912 org.apache.fop.fo.flow.TableRow > 81024 org.apache.fop.datatypes.Keep > 81024 org.apache.fop.fo.KeepProperty > 54432 org.apache.fop.fo.flow.TableRow$CellArray > -------- > 20100536 bytes > > Another 18MB of java base objects like HashMap also contribute quite a > bit. This means that memory is already pretty tight before the layout > process even starts. I also the repeated font-size="8pt" and > text-align="start" causes some bloat, and deleting them reduced the > overall number of created objects by 10%. However, the effect on run > time was neglible. > > Increasing the mx setting resulted in memory thrashing :-/. > > A closer look at the memory profiler statistics showed that all the > layout data associated with table cells still hung around in memory at > the time memory runs out. Digging further this turned out to be caused > by table objects clinging to their layout data indefinitely. That's > bad. I put in a small hack, using the area's back pointer to release > the data for Table, AbstractTableBody, TableRow and TableCell after > rendering. This allowed me to render the file, albeit slowly due to > frequent GC. Unfortunately I'm reluctant to commit the change because > it is likely to break some things, in particular putting IDs on a > table will cause trouble in certain situations. This could probably > be fixed too, but the more the scope of the code change is broadened > the more testing would be necessary before the next release. > > Conclusion: don't use tables, as they lock up a lot of memory until > the page sequence ends. If you have to use tables, use short page > sequences. > > Some additional notes: the most objects created in total were of class > String (3'738'853), which is no surprise, followed by java.lang.Object > (571'663), ArrayList (389'319), HashMap$Entry(278'527) and HashMap > (122'702), which *is* a bit of a surprise. I guess the j.l.Object > counts the various arrays. Hashmap entries, lists and the objects > tended to be fairly persistent, with more than 100'000 lists and > objects as well as 135'000 hashmap entries still being referenced at > the end of the run. The hashmaps itself are less likely to be kept, > only 7'500 out of a total of 122'000 have been left. This means the > persistently referenced hashmaps keep an average of 13 entries, while > the overall average is 4.7 entries per hash map. A few maps with lots > of entries, like the ones holding the mapping from element names to > element factories may account for much of the difference. OTOH the low > overall average indicates that many of the hashmaps stay empty, there > ought to be quite some potential for optimization. I suspect many of > the lists stay empty too. Does anybody have ideas or knowledge of > tools which allow more detailed investigations of this kind of issues? > > J.Pietschmann > > > --------------------------------------------------------------------- > 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]
report.pdf
Description: Adobe PDF document
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
