Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (hermes.apache.org: domain of davanum@gmail.com designates
 64.233.170.195 as permitted sender)
Message-ID: <19e0530f040913231542db0d84@mail.gmail.com>
Date: Tue, 14 Sep 2004 11:45:13 +0530
From: Davanum Srinivas <davanum@gmail.com>
Reply-To: dims@apache.org
To: axis-dev@ws.apache.org, avolanis@rsasecurity.com
Subject: Re: Patch: Memory leak in DeserializationContextImpl.parce() fixed
Cc: iasandcb@tmax.co.kr
In-Reply-To: 
 <017630AA6DF2DF4EBC1DD4454F8EE297040EF72B@rsana-ex-hq1.NA.RSA.NET>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <017630AA6DF2DF4EBC1DD4454F8EE297040EF72B@rsana-ex-hq1.NA.RSA.NET>

Alex,

It was on my TODO...sorry for the delay. I have checked it in now.

-- dims


On Mon, 13 Sep 2004 12:28:55 -0400, Volanis, Alexander
<avolanis@rsasecurity.com> wrote:
> Greetings Axis Developers,
> 
> I notice continued complains from users about memory leaks in Axis 1.2
> betas. The submitted patch from the original message in this thread
> seems to have slipped through the cracks. Even though
> DeserializationContextImpl has been refactored into the
> DeserializationContext interface making the latter into a class the fix
> did not make it in the current code. We have been using this simple fix
> in the Axis 1.1 codebase for our application usage and it has
> dramatically reduced the memory footprint of Axis and every tool we use
> (Jprobe/OptimizeIt) no longer reports unwaranted memory retention by
> Axis classes. I would hate to see Axis 1.2 released for GA without
> making this simple change. As Ias confirmed to be the case, the code in
> place is simply wrong, by the SAX spec, and it should be changed.
> 
> Regards,
> Alex Volanis
> 
> -----Original Message-----
> From: Ias [mailto:iasandcb@tmax.co.kr]
> Sent: Monday, May 31, 2004 10:16 AM
> To: axis-dev@ws.apache.org; dims@apache.org
> Subject: RE: Patch: Memory leak in DeserializationContextImpl.parce()
> fixed
> 
> > Ias,
> >
> > can we please add a switch to switch it on? as it may work in some
> > environments?
> 
> In my opinion, any SAX-compliant parser such as Xerces and Crimson
> should work as the description said, so setting NullLexicalHandler all
> the time seems good in terms of both scalable performance and proper
> usage.
> 
> Regards,
> 
> Ias
> 
> >
> > thanks,
> > dims
> >
> > On Mon, 31 May 2004 16:20:54 +0900, Ias <iasandcb@tmax.co.kr> wrote:
> > >
> > > > Hello Axis Developers,
> > > >
> > > > We use Axis 1.1 in one of our products and as a result of
> > a number
> > > > of performance tests we identified a memory leak in
> > > > org.apache.axis.encoding.DeserializationContextImpl.parse()
> > > > method. The way the code was attempting to remove the
> > reference to
> > > > "this" from the instance of SAXParser is just plain
> > wrong. Looking
> > > > into Xerces code for the
> > > > SAXParcerImpl.setProperty() method null is not an
> > acceptable value.
> > >
> > > FYI, according to
> > >
> > http://www.saxproject.org/apidoc/org/xml/sax/package-summary.html#pack
> > > age_de
> > > scription
> > >
> > > lexical-handler
> > >
> > > Used to see some syntax events that are essential in some
> > applications:
> > > comments, CDATA delimiters, selected general entity inclusions, and
> > > the start and end of the DTD (and declaration of document element
> > > name). The Object must implement org.xml.sax.ext.LexicalHandler.
> > >
> > > Therefore, null value is unacceptable for the property in
> > the sense above.
> > >
> > > Thanks,
> > >
> > > Ias
> > >
> > >
> > >
> > > > I added a NullLexicalHandler inner class that can be used
> > to remove
> > > > the reference and allow memory to be released.
> > > > Although it is not significant under light load conditions the
> > > > complexity of the messages and the load can cause the pool of
> > > > SAXParser instances maintained by XMLUtils to grow significantly.
> > > > The amount of memory that is held by each instance of
> > > > DeserializationContextImpl can be significant as the message size
> > > > grows. Examining the system with Jprobe helped us identify the
> > > > source of the problem and make this change which corrected the
> > > > problem for our application using Axis 1.1 Final.
> > > >
> > > > The attached unified diff is against the latest CVS for Axis 1.2.
> > > > The exact same code would work in 1.1 as well, the diff
> > is trivial
> > > > to apply.
> > > >
> > > > I do not have CVS accees but I used the ViewCVS facility
> > to download
> > > > version 1.81 of this file and make the changes.
> > > > Would anyone of the commiters care to verify this fix and apply?
> > > >
> > > > Regards,
> > > > Alex Volanis
> > > >
> > > >
> > >
> > >
> >
> 
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/