Thanks your feedback, Kevin. Wish your system run smoothly and all of us have a good night's sleep ;) We also will keep an eye on it and trace it in this issue: https://issues.apache.org/jira/browse/ODFTOOLKIT-104.
2011/11/22 Kevin Skelton <[email protected]> > Good news. It looks like the issue I am having with the ODF lockups is > due to the JDK version we are running on Linux (JDK1.6.0_18 ). > JDK1.6.0_18 seems to have a number of changes regarding garbage > collection. > > We installed an older version of the JDK (JDK1.6.0_13) and I could not > recreate my issue of locking up. > I also could not recreate my issue on a newly installed JDK1.6.0_27 (64 > bit). > > We will upgrade the JDK in production and keep an eye on it. > > Thanks for your help, > Kevin > > > > > > From: > Devin Han <[email protected]> > To: > [email protected] > Date: > 11/18/2011 01:32 AM > Subject: > Re: TextDocument.loadDocument() locking up in an x86_Linux_64 environment. > > > > Sorry, Kevin . I can't reproduce this issue after trying several times.... > But I will continue to do it. > Could you tell me how serious is this issue for you application? If > possible, could you give us more information about you application and > test > environment? > > 2011/11/17 Kevin Skelton <[email protected]> > > > Devin, > > > > I received you .jar file once it was released from our quarantine. > > I installed it and reran my test (both with 0.6.5 and 0.6.6). The > process > > made it farther this time, but still locked up and began thrashing the > > cpu. > > So while it appears to have improved somewaht, I am still having the > same > > issue. > > > > > > > > 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: > > Devin Han <[email protected]> > > To: > > [email protected] > > Date: > > 11/16/2011 03:20 AM > > Subject: > > Re: TextDocument.loadDocument() locking up in an x86_Linux_64 > environment. > > > > > > > > Hi Kevin, > > > > Long time didn't hear from you. Thank you for continue help us to > improve > > ODF Toolkit in Apache. > > > > I found a bug in ODFDOM that maybe the reason of this issue. see the > > following code from OdfPackage > > > > // Initialize using memory > > private void initializeZip(InputStream odfStream) throws Exception { > > ByteArrayOutputStream tempBuf = new ByteArrayOutputStream(); > > StreamHelper.transformStream(odfStream, tempBuf); > > byte[] mTempByteBuf = tempBuf.toByteArray(); > > tempBuf.close(); > > > > > > ---------------------------------------------------------------------------------------------------------->!!!!!!!!!!!!!! > > odfStream doesn't close > > if (mTempByteBuf.length < 3) { > > OdfValidationException ve = new > > OdfValidationException(OdfPackageConstraint.PACKAGE_IS_NO_ZIP, > > getBaseURI()); > > if (mErrorHandler != null) { > > mErrorHandler.fatalError(ve); > > } > > throw new IllegalArgumentException(ve); > > } > > mZipFile = new ZipHelper(this, mTempByteBuf); > > readZip(); > > } > > > > In this method, the opened file stream isn't closed, which will lead OS > > can't recovery the file handler. > > > > add the following code to the target: > > // close the input stream to notify OS release file handle. > > odfStream.close(); > > > > I will send a private jar to you, please check whether the issue has > been > > resolved. If yes, I will create a formal patch and commit it to the > master > > repository. > > > > @Ashok Thank you very much for you kindly help to reproduce the issue. > > > > BTW 1: we have a similar discussion before, see > > https://issues.apache.org/jira/browse/ODFTOOLKIT-104. > > > > BTW 2: share this table to help you learn more about the process of ODF > > Toolkit load document and its cache policy. ODF Toolkit doesn't lock the > > loaded document, so for multithread application read, it is also safe. > > > > Step > > > > Key Sub Step > > > > New Memory Cost > > > > 1. Load Document > > > > 1.1 Create OdfPackage > > > > Cache the document as byte array > > > > 2. Access Document > > > > 2.1 Unzip ZipEntry > > > > Cache unziped data as byte array > > > > 2.2 Parse DOM Tree with SAX API > > > > Cache the whole DOM tree > > > > 2011/11/16 Kevin Skelton <[email protected]> > > > > > Ashok, > > > > > > I added your GC to startup and removed System.gc(); > > > The 1,000 loop test still crashed. > > > > > > One thing I did do was switch to using a FileInputStream which seemed > to > > > help a bit (file handles actually close), but eventually still crashed > > > anyway. > > > > > > FileInputStream fis = new FileInputStream("/home2/templates/" + > > > templateName); > > > textDoc = (TextDocument)TextDocument.loadDocument(fis); > > > fis.close(); > > > > > > > > > > > > Kevin > > > > > > > > > > > > From: > > > Ashok Hariharan <[email protected]> > > > To: > > > [email protected] > > > Date: > > > 11/15/2011 02:11 PM > > > Subject: > > > Re: TextDocument.loadDocument() locking up in an x86_Linux_64 > > environment. > > > > > > > > > > > > On Tue, Nov 15, 2011 at 10:10 PM, Kevin Skelton > <[email protected]> > > > wrote: > > > > 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. > > > > > > > > > > Try removing the System.gc() > > > > > > and starting the test app with -XX:-UseParallelGC > > > > > > do you get the same problem ? > > > > > > > > > > > > > > > -- > > -Devin > > > > > > > > > -- > -Devin > > > -- -Devin
