From odf-users-return-32-apmail-incubator-odf-users-archive=incubator.apache.org@incubator.apache.org Tue Nov 15 18:46:50 2011 Return-Path: X-Original-To: apmail-incubator-odf-users-archive@minotaur.apache.org Delivered-To: apmail-incubator-odf-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 37A207F25 for ; Tue, 15 Nov 2011 18:46:50 +0000 (UTC) Received: (qmail 90601 invoked by uid 500); 15 Nov 2011 18:46:50 -0000 Delivered-To: apmail-incubator-odf-users-archive@incubator.apache.org Received: (qmail 90555 invoked by uid 500); 15 Nov 2011 18:46:50 -0000 Mailing-List: contact odf-users-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: odf-users@incubator.apache.org Delivered-To: mailing list odf-users@incubator.apache.org Received: (qmail 90547 invoked by uid 99); 15 Nov 2011 18:46:50 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Nov 2011 18:46:50 +0000 Received: from localhost (HELO mail-vw0-f47.google.com) (127.0.0.1) (smtp-auth username robweir, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Nov 2011 18:46:49 +0000 Received: by vwe42 with SMTP id 42so6607502vwe.6 for ; Tue, 15 Nov 2011 10:46:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.33.140 with SMTP id r12mr45246513vdi.36.1321382808880; Tue, 15 Nov 2011 10:46:48 -0800 (PST) Received: by 10.220.218.139 with HTTP; Tue, 15 Nov 2011 10:46:48 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Nov 2011 13:46:48 -0500 Message-ID: Subject: Re: TextDocument.loadDocument() locking up in an x86_Linux_64 environment. From: Rob Weir To: odf-users@incubator.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Nov 15, 2011 at 1:24 PM, Kevin Skelton wro= te: > =C2=A0Running 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. =C2=A0Problem did = not go > away. > > textDoc =3D (TextDocument)TextDocument.loadDocument("/home2/.../templates= /" > + templateName); > > 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. =C2=A0For further testing I counted the number of file handles an= d > memory available on every load. > It does not seem to be related to number of file handles or heap memory > consumed. =C2=A0Free memory is well within limits and the file handle cou= nt > does drop back down to "normal". > > Eventually, I placed the loadDocument() in a loop of 1,000 loads. =C2=A0J= ava > handled it all pretty well and garbage collecting eventually brought the > File handle count from 1,049 back down to around 49. =C2=A0Shortly therea= fter > 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 debugg= ing. Regards, -Rob > > Kevin Skelton > MGIC Business Acquisition > 414-347-6337 > > This message is intended for use only by the person(s) addressed above an= d > 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 thi= s > message. >