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
