incubator-odf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Devin Han <devin...@apache.org>
Subject Re: TextDocument.loadDocument() locking up in an x86_Linux_64 environment.
Date Wed, 16 Nov 2011 09:20:11 GMT
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 <Kevin_Skelton@mgic.com>

> 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 <ashok@parliaments.info>
> To:
> odf-users@incubator.apache.org
> 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 <Kevin_Skelton@mgic.com>
> 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

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