incubator-odf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Skelton <>
Subject Re: TextDocument.loadDocument() locking up in an x86_Linux_64 environment.
Date Wed, 16 Nov 2011 16:08:00 GMT

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 
So while it appears to have improved somewaht, I am still having the same 

Kevin Skelton
MGIC Business Acquisition

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 

Devin Han <>
11/16/2011 03:20 AM
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();
odfStream doesn't close
        if (mTempByteBuf.length < 3) {
            OdfValidationException ve = new
            if (mErrorHandler != null) {
            throw new IllegalArgumentException(ve);
        mZipFile = new ZipHelper(this, mTempByteBuf);

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.

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

@Ashok  Thank you very much for you kindly help to reproduce the issue.

BTW 1: we have a similar discussion before, see

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.


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

> 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 <>
> To:
> Date:
> 11/15/2011 02:11 PM
> Subject:
> Re: TextDocument.loadDocument() locking up in an x86_Linux_64 
> On Tue, Nov 15, 2011 at 10:10 PM, Kevin Skelton <>
> 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 
> > an exception.
> >
> Try removing the System.gc()
> and starting the test app with -XX:-UseParallelGC
> do you get the same problem ?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message