incubator-odf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: TextDocument.loadDocument() locking up in an x86_Linux_64 environment.
Date Tue, 15 Nov 2011 18:46:48 GMT
On Tue, Nov 15, 2011 at 1:24 PM, Kevin Skelton <> wrote:
>  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

Hi Kevin,

Can you say a little more about what your program is doing?  Is it
only reading documents?  Or is it a read/write scenario?  Is it
multi-threaded or single threaded?

> 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.

Are you seeing any other errors or exceptions before that point?

> 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();

I assume you are reading 1000 different documents?  Or is it the same
document over and over again?  Is there anything special about the
document that is being loaded on the iteration where you hang?  Is it
always hanging on the same document?

> 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.

Can you describe more what this "hang" is like?  Is like a runaway
loop where the CPU is pegged at 100%? Or is it more like a deadlock
state where the CPU is at 0%?  I'm assuming only the JVM is hung, not
the system.  Also, in some JVM's, if you do a Control-Break, you'll
get a stack trace. It would be interesting to see what that is when
you're locked up.

> Any ideas?

More questions than answers at this point.  But that's the nature of debugging.



> 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.

View raw message