incubator-odf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Skelton <Kevin_Skel...@mgic.com>
Subject TextDocument.loadDocument() locking up in an x86_Linux_64 environment.
Date Tue, 15 Nov 2011 18:24:16 GMT
 Running Simple api 0.6.5 (also tried 0.6.6) on a Linux64 x86 server on 
top of odf 0.8.7 with xerces 2.9.1.
JDK 1.6.0_18

Performing explicit close of TextDocument after processing complete. 
Garbage collection does not immediately close the file handle.
Eventually, the stand-alone Java process simply stops running (locks up) 
while trying to open an .odt file. 
First tried increasing the heap size from 786 to 1536.  Problem did not go 
away.

textDoc = (TextDocument)TextDocument.loadDocument("/home2/.../templates/" 
+ templateName); 
<snip>
textDoc.clearList();
textDoc.close();



This is very hard to recreate. We can run for some time before the error 
occurs.  For further testing I counted the number of file handles and 
memory available on every load.
It does not seem to be related to number of file handles or heap memory 
consumed.  Free memory is well within limits and the file handle count 
does drop back down to "normal".

Eventually, I placed the loadDocument() in a loop of 1,000 loads.  Java 
handled it all pretty well and garbage collecting eventually brought the 
File handle count from 1,049 back down to around 49.  Shortly thereafter 
the Java process locks up.

If I add in a System.gc() call, then the file handles stay at 49 
constantly and I always lock up on the 313th iteration of my 1,000 
iterating loop.

Any ideas?


Kevin Skelton
MGIC Business Acquisition
414-347-6337

This message is intended for use only by the person(s) addressed above and 
may contain privileged and confidential information. Disclosure or use of 
this message by any other person is strictly prohibited. If this message 
is received in error, please notify the sender immediately and delete this 
message.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message