incubator-odf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Skelton <Kevin_Skel...@mgic.com>
Subject Re: TextDocument.loadDocument() locking up in an x86_Linux_64 environment.
Date Mon, 21 Nov 2011 17:39:20 GMT
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



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