OutOfMemory Error

[jbeltran]

I'm receiving the following OutOfMemory Error

Code: Select all

Caused by: java.lang.OutOfMemoryError: Java heap space
   at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:95)
   at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
   at java.io.BufferedOutputStream.write(BufferedOutputStream.java:78)
   at org.docx4j.openpackaging.io.LoadFromZipNG.getBytesFromInputStream(LoadFromZipNG.java:114)
   at org.docx4j.openpackaging.io.LoadFromZipNG.get(LoadFromZipNG.java:167)


The files were dealing with aren't too large, but we are loading a lot of files 50+ with the same request. Any ideas how to deal with this issue?

Thanks,
Justin

[jason]

Can you increase your heap (using JVM arg)?

See also viewtopic.php?f=6&t=208 - try using LoadFromZipFile (as opposed to NG).

[jbeltran]

Unfortunately, the people who administer our servers aren't willing to increase the memory settings. Currently when starting up our application server (OC4J), we allocate this much: -Xms64M -Xmx640M

Where would I switch out LoadFromZipFileNG? Looks like the call is in WordporcessingMLPackage.load(). What's the difference between the two? Will I lose out on any functionality if I do switch to LoadFromZipFile instead? Anyway, I modified the code as follows:

Code: Select all

      LoadFromZipFile loader = new LoadFromZipFile();
      //LoadFromZipNG loader = new LoadFromZipNG();
      return (WordprocessingMLPackage)loader.get(docxFile);      
      /*
      FileInputStream fis = null;
      try {
         fis = new FileInputStream(docxFile);
      } catch (FileNotFoundException e) {
         log.error(e);
         throw new Docx4JException("Couldn't load docx from " + docxFile.getAbsolutePath(), e);
      }
      return (WordprocessingMLPackage)loader.get(fis);
      */


Just wanted to check if that was correct.

[jason]

NG is a refactoring which allows the zip to be loaded from an inputstream. at the cost of creating temporary byte arrays (they should get garbage collected).

LoadFromZipFile does not have that method; also, if you use its .setConserveMemory(true), it will only load binary part data when it is actually needed, storing it in a soft reference so it can be unloaded by the jvm if free memory is low. You could try it with and without it set to conserve memory.

In other respects the 2 classes are pretty much the same.

cheers .. Jason