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 Tue, 22 Nov 2011 02:45:58 GMT
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 <Kevin_Skelton@mgic.com>

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


-- 
-Devin

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