Fatal java.lang.OutOfMemoryError thrown while processing document about cermine

[marekhorst]

Dear Dominika, long time no see ;)

We've just found one another file among the ones processed by OpenAIRE:
https://comum.rcaap.pt/bitstream/10400.26/19846/1/Reis_Ivo_Miguel_de_Castro.pdf

available also from:
http://hdl.handle.net/10400.26/19846

causing very similar fatal exception:

java.lang.OutOfMemoryError: Java heap space
	at java.util.Arrays.copyOf(Arrays.java:3236)
	at java.io.ByteArrayOutputStream.toByteArray(ByteArrayOutputStream.java:191)
	at com.itextpdf.text.pdf.PdfReader.decodePredictor(PdfReader.java:2101)
	at com.itextpdf.text.pdf.FilterHandlers$Filter_FLATEDECODE.decode(FilterHandlers.java:108)
	at com.itextpdf.text.pdf.PdfReader.decodeBytes(PdfReader.java:2619)
	at com.itextpdf.text.pdf.parser.PdfImageObject.<init>(PdfImageObject.java:189)
	at com.itextpdf.text.pdf.parser.PdfImageObject.<init>(PdfImageObject.java:168)
	at com.itextpdf.text.pdf.parser.ImageRenderInfo.prepareImageObject(ImageRenderInfo.java:150)
	at com.itextpdf.text.pdf.parser.ImageRenderInfo.getImage(ImageRenderInfo.java:140)
	at pl.edu.icm.cermine.structure.ITextCharacterExtractor$BxDocumentCreator.renderImage(ITextCharacterExtractor.java:366)
	at com.itextpdf.text.pdf.parser.PdfContentStreamProcessor$ImageXObjectDoHandler.handleXObject(PdfContentStreamProcessor.java:1311)
	at com.itextpdf.text.pdf.parser.PdfContentStreamProcessor.displayXObject(PdfContentStreamProcessor.java:375)
	at com.itextpdf.text.pdf.parser.PdfContentStreamProcessor.access$6100(PdfContentStreamProcessor.java:83)
	at com.itextpdf.text.pdf.parser.PdfContentStreamProcessor$Do.invoke(PdfContentStreamProcessor.java:1023)
	at com.itextpdf.text.pdf.parser.PdfContentStreamProcessor.invokeOperator(PdfContentStreamProcessor.java:310)
	at com.itextpdf.text.pdf.parser.PdfContentStreamProcessor.processContent(PdfContentStreamProcessor.java:448)
	at pl.edu.icm.cermine.structure.ITextCharacterExtractor.extractCharacters(ITextCharacterExtractor.java:112)
	at pl.edu.icm.cermine.ExtractionUtils.extractCharacters(ExtractionUtils.java:60)
	at pl.edu.icm.cermine.InternalContentExtractor.doWork(InternalContentExtractor.java:346)
	at pl.edu.icm.cermine.InternalContentExtractor.doWork(InternalContentExtractor.java:339)
	at pl.edu.icm.cermine.InternalContentExtractor.doWork(InternalContentExtractor.java:339)
	at pl.edu.icm.cermine.InternalContentExtractor.doWork(InternalContentExtractor.java:339)
	at pl.edu.icm.cermine.InternalContentExtractor.doWork(InternalContentExtractor.java:339)
	at pl.edu.icm.cermine.InternalContentExtractor.doWork(InternalContentExtractor.java:339)
	at pl.edu.icm.cermine.InternalContentExtractor.doWork(InternalContentExtractor.java:339)
	at pl.edu.icm.cermine.InternalContentExtractor.getContentAsNLM(InternalContentExtractor.java:299)
	at pl.edu.icm.cermine.ContentExtractor.getContentAsNLM(ContentExtractor.java:662)
	at pl.edu.icm.cermine.ContentExtractor.getContentAsNLM(ContentExtractor.java:678)
	at eu.dnetlib.iis.wf.metadataextraction.MetadataExtractorMain.processFile(MetadataExtractorMain.java:112)
	at eu.dnetlib.iis.wf.metadataextraction.MetadataExtractorMain.process(MetadataExtractorMain.java:88)
	at eu.dnetlib.iis.wf.metadataextraction.MetadataExtractorMain.main(MetadataExtractorMain.java:60)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

The only difference is now we need to increase Xmx memory upt to 10g to avoid memory related errors. Execution time reaches 7 minutes then.

When you compare both stack traces you will find common line related to CERMINE code:

pl.edu.icm.cermine.structure.ITextCharacterExtractor$BxDocumentCreator.renderImage(ITextCharacterExtractor.java:366)

do you think we could somehow make CERMINE immune to OutOfMemoryErrors at that point? Those errors are pretty nasty because whole bulk processing is interrupted.

I could contribute to your code but first I would need to know whether the problem is with CERMINE or iText library. Unfortunately my current understanding of what in fact is going on is pretty vague, apart from the well known fact we are trying to read image object which seem to be very large. File size is ~90MB and we need 10GB of memory to process it so it smells like some memory leak to me.

[marekhorst]

For the record: I just found another file:
https://users.cs.cf.ac.uk/Yukun.Lai/papers/morphingCGF16.pdf

causing very same exception. File size: 16MB, xmx memory required: 8g.

[dtkaczyk]

Dear Marek, I finally come to the rescue :)

In all three cases the problem seems to be too many and/or too big images in the file. I was able to fix this (commit 6a253f2) for the files: Reis_Ivo_Miguel_de_Castro.pdf (contains the scans of the pages) and morphingCGF16.pdf (contains duplicate images displayed on top of each other). In the case of PhD_Thesis_Maria_Manuela_Marinho_de_Castro.pdf, however, I don't see anything suspicious, it just seems there are a lot of heavy images.

One easy fix for you might be to turn off image extraction completely. IIS is not interested in images, right? This should do the trick:

ExtractionConfigBuilder builder = new ExtractionConfigBuilder(); builder.setProperty(ExtractionConfigProperty.IMAGES_EXTRACTION, false); ExtractionConfigRegister.set(builder.buildConfiguration());

[marekhorst]

Thank you Dominika for sacrificing your precious time, especially during the weekend! I really appreciate it.

One easy fix for you might be to turn off image extraction completely. IIS is not interested in images, right?

Is CERMINE capable of extracting any kind of metadata information out of images? Will we loose anything when disabling images extraction?

If the answer is no, then this is exactly what I was looking for and it may solve all our problems. I've just run several tests and it works like a charm. This could also give us the opportunity to decrease metadataextraction phase memory footprint and as a result of that increase parallelism on a cluster.

You made my whole week! I wish I could start every Monday witch such a treat :)

[dtkaczyk]

No, no metadata is extracted from the images. Extracting images was added after a request from one of CERMINE's users. It can be useful, however, now I think it should be off by default, perhaps I will make such a change later this week.

[marekhorst]

No, no metadata is extracted from the images.

OK, this means we can skip it.

Extracting images was added after a request from one of CERMINE's users. It can be useful, however, now I think it should be off by default, perhaps I will make such a change later this week.

Yes, I guess this is good idea. Especially knowing this may take a lot of memory resources sometimes leading to unrecoverable fatal OutOfMemoryErrors.

[marekhorst]

I have applied appropriate fix in IIS metadata extraction phase: openaire/iis@913887d.

I guess we can close this issue.

[marekhorst]

One additional note: I've managed to execute CERMINE on all problematic contents we've gathered so far:

http://ci.ceon.pl/view/IIS/job/metadataextraction_smoke_test/58/

with only 1GB of xmx memory made available to this job. Job succeeded what indicates we've managed to reduce memory footprint significantly and probably we could reduce 4GB to 1GB for all contents we have in OpenAIRE. This way metadata extraction phase could run 4x faster (4x more mappers could be instantiated at the same time).