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 Re: TextDocument.loadDocument() locking up in an x86_Linux_64 environment.
Date Tue, 15 Nov 2011 19:10:34 GMT
The program is loading an .odt doc from the linux file system in order to 
match/merge it with a data file.
I am not writing or saving the document back to the file system, I am 
sending the newly created doc over the wire.
This is a single threaded application.  (MQSeries triggered).

No exceptions at all.  I have the load in a try/catch loop but never see 
an exception.

Here is one version of my code for my 1000 iteration loop test.
Looping over the same document in this test.
Does not matter which .odt file I use. 


          for (int i = 0; i < 1000; i++) {
 
            try {
 
               long freeMemory  = rt.freeMemory();
               long totalMemory = rt.totalMemory();
               long maxMemory   = rt.maxMemory();
               long memoryUsed  = maxMemory - freeMemory; 
 
               log.debug("MemUsed= " + memoryUsed + " |FreeMem= " + 
freeMemory  + " |TotMem= " + totalMemory + " |MaxMem= " + maxMemory  );
               log.debug("createForm() - Loading Template: " + 
templateName + " | FileHndlCnt = "+ getFileHandleCnt()); 
 
                   textDoc = (TextDocument)TextDocument.loadDocument(
"/home2/templates/" + templateName);     //String Document path
 
               }
               // Testing logic to close textDoc 
               //textDoc.clearList();
               textDoc.close();
               System.gc();  // causes crash after 313th iteration.  If 
not used process crashes after garbage collection occurs.
               log.debug( i + "  createForm() - Template Found | 
FileHndlCnt = " + getFileHandleCnt()); 
 
 
            } catch (Exception e ){
               log.error("createForm()  Template not found: " + 
templateName );
               textDoc.close();
               return null;
            }
 
         } 


The hanging is pegging the CPU at 100% according to the 'top' command. 
Cacti trace also shows a spike of cpu.
Don't think I have a way to control-break the server process.



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.




From:
Rob Weir <robweir@apache.org>
To:
odf-users@incubator.apache.org
Date:
11/15/2011 12:46 PM
Subject:
Re: TextDocument.loadDocument() locking up in an x86_Linux_64 environment.



On Tue, Nov 15, 2011 at 1:24 PM, Kevin Skelton <Kevin_Skelton@mgic.com> 
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.

Regards,

-Rob


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