You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Kevin <kb...@yahoo.com> on 2007/10/03 03:04:08 UTC

Re: Outofmemory (with heapdump contents) -

Hi,

I did some additional testing to isolate the OOM issue and found that its
happening in the AREA TREE -> PDF transform step.

In order  to create a PDF, I have to do the  following:

XML(100) -> FO -> AREA TREE(1) -> AREA TREE(2) -> PDF

I am doing some post processing in AREA TREE(1) which produces AREA TREE(2).

The PDF  generation happens in a batch process with 100 documents per PDF file.
I enabled GC during the batch. The heap size was set to 768MB. What I noticed
was by the end of 10th file creation, the OOM happenned and the java process
memory utilization(in task manager) kept increasing for every PDF file creation
and finally ended with a OOM. Even though GC was hapening regularly, the % of
free space kept on decreasing.

The heapdump that got created during OOM had pretty much the same object tree as
in my previous post. 

Below it the code I use for AREA TREE(2) -> PDF transformation:
				FopFactory fopFactory = FopFactory.newInstance();

				// Used to find images
				fopFactory.setURIResolver(TIPResourceResolver.DEFAULT_URI_RESOLVER);

				OutputStream out2 = ((StreamResult)result).getOutputStream();
				if (out2 == null)
				{
					throw new IllegalArgumentException("PDF production requires an OutputStream
for binary data, not a 
Writer, which is for character data.");
				}
				//Setup fonts and user agent
				FontInfo fontInfo = new FontInfo();
				FOUserAgent userAgent = fopFactory.newFOUserAgent();

				//Construct the AreaTreeModel that will received the individual pages
				AreaTreeModel treeModel = new RenderPagesModel(userAgent,
MimeConstants.MIME_PDF, fontInfo, out2);

				//Iterate over all intermediate files
				AreaTreeParser parser = new AreaTreeParser();

				// Read area tree
				StreamSource atSource = new StreamSource(new
FileInputStream(areaTreeFileWithOmr));

				parser.parse(atSource, treeModel, userAgent);

				//Signal the end of the processing. The 
renderer can finalize the target document.
				treeModel.endDocument(); 


Please let me know if you have any comments or suggestions.

Thanks
Kevin


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Outofmemory (with heapdump contents) -

Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
To reproduce your problem I took your code and wrote some code around it
to generate an area tree file for 2000 documents with 10 pages each. The
area tree file was 800MB. The generation of the area tree file and the
subsequent rendering of the area tree to PDF went through with constant
memory consumption while the the JVM was on default memory settings. So
that means I cannot reproduce your problem. No idea what's wrong on your
side without working with exactly the data and setup you do.

Can you try rendering the area tree file from FOP's command-line and
check if the same happens? That would help rule out other reasons for
the OOM.

Jeremias Maerki



On 03.10.2007 03:04:08 Kevin wrote:
> Hi,
> 
> I did some additional testing to isolate the OOM issue and found that its
> happening in the AREA TREE -> PDF transform step.
> 
> In order  to create a PDF, I have to do the  following:
> 
> XML(100) -> FO -> AREA TREE(1) -> AREA TREE(2) -> PDF
> 
> I am doing some post processing in AREA TREE(1) which produces AREA TREE(2).
> 
> The PDF  generation happens in a batch process with 100 documents per PDF file.
> I enabled GC during the batch. The heap size was set to 768MB. What I noticed
> was by the end of 10th file creation, the OOM happenned and the java process
> memory utilization(in task manager) kept increasing for every PDF file creation
> and finally ended with a OOM. Even though GC was hapening regularly, the % of
> free space kept on decreasing.
> 
> The heapdump that got created during OOM had pretty much the same object tree as
> in my previous post. 
> 
> Below it the code I use for AREA TREE(2) -> PDF transformation:
> 				FopFactory fopFactory = FopFactory.newInstance();
> 
> 				// Used to find images
> 				fopFactory.setURIResolver(TIPResourceResolver.DEFAULT_URI_RESOLVER);
> 
> 				OutputStream out2 = ((StreamResult)result).getOutputStream();
> 				if (out2 == null)
> 				{
> 					throw new IllegalArgumentException("PDF production requires an OutputStream
> for binary data, not a 
> Writer, which is for character data.");
> 				}
> 				//Setup fonts and user agent
> 				FontInfo fontInfo = new FontInfo();
> 				FOUserAgent userAgent = fopFactory.newFOUserAgent();
> 
> 				//Construct the AreaTreeModel that will received the individual pages
> 				AreaTreeModel treeModel = new RenderPagesModel(userAgent,
> MimeConstants.MIME_PDF, fontInfo, out2);
> 
> 				//Iterate over all intermediate files
> 				AreaTreeParser parser = new AreaTreeParser();
> 
> 				// Read area tree
> 				StreamSource atSource = new StreamSource(new
> FileInputStream(areaTreeFileWithOmr));
> 
> 				parser.parse(atSource, treeModel, userAgent);
> 
> 				//Signal the end of the processing. The 
> renderer can finalize the target document.
> 				treeModel.endDocument(); 
> 
> 
> Please let me know if you have any comments or suggestions.
> 
> Thanks
> Kevin


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Outofmemory (with heapdump contents) -

Posted by Chris Bowditch <bo...@hotmail.com>.
Kevin wrote:

> Hi,
> 
> I did some additional testing to isolate the OOM issue and found that its
> happening in the AREA TREE -> PDF transform step.

Maybe you mentioned this in another thread, but what version of FOP are 
you using? Is it a self build from trunk?

I've no idea why this should happen since you have broken the 300 pages 
up into separate sequences. I have a similar processing chain and can 
generate much larger PDFs files without hitting this error.

<snip/>

Chris



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org