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 Fri, 18 Nov 2011 07:32:42 GMT
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 <Kevin_Skelton@mgic.com>

> 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 <devinhan@apache.org>
> To:
> odf-users@incubator.apache.org
> 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 <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
>
>
>


-- 
-Devin

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