Hi, The problem was in the context. I had to call cleanupContexts and terminate on the context for the memory leak to go away in axis 1.5.1 client code. So either try not create context each time (right thing to do) or call the above two methods to clean them up after each call. The best option is to pool the stub which worked very well for me and gave better performance as well.
Thanks, Sanjay -----Original Message----- From: ceri tandogan [mailto:[email protected]] Sent: Wednesday, June 16, 2010 11:46 PM To: [email protected] Subject: Re: BackportUtil jar causing memory leak Hello, We've analysed it with Artus Applicare and Jboss profiler. There is nothing strange for Axis 1.5. We are using axis on server side and on client side. Both of them seems fine. what kind of tuning tool are you using ? what kind of model are you using?(on client side? on server side? ADB,XMLBeans...) Details: We've used XMLBeans for generating classes. because we're a little bit familiar with apache xmlbeans and we've had difficulties when generating some classes with ADB. Ceri ----- Original Message ---- From: Sanjay Gupta <[email protected]> To: "[email protected]" <[email protected]> Sent: Thu, June 17, 2010 12:08:40 AM Subject: RE: BackportUtil jar causing memory leak Hi Ceri, Apart from using 1.5 , did you do anything else. I just upgraded to 1.5.1 from 1.4.1 and still see memory leak. Would appreciate any help. Sanjay -----Original Message----- From: ceri tandogan [mailto:[email protected]] Sent: Wednesday, June 16, 2010 1:28 PM To: [email protected]; [email protected] Cc: [email protected] Subject: Re: BackportUtil jar causing memory leak Yes, definitely. I'm using axis 1.5, it works fine and no memory leak is observed. I think this library is replaced by axis2 transport jar. Ceri ----- Original Message ---- From: "FRYARS, Michael" <[email protected]> To: [email protected] Cc: [email protected] Sent: Wed, June 16, 2010 10:29:55 PM Subject: re: BackportUtil jar causing memory leak Hi, can anyone tell me if the problem discussed below ("BackportUtil jar causing memory leak") was ever verified to be a genuine problem in Axis2 1.4 ? Was this a one-off report of the problem, or is it know to be a general/repeatable issue? And does it definitely go away from Axis2 1.5 onwards? Thanks in advance. http://mail-archives.apache.org/mod_mbox/axis-java-user/201003.mbox/%[email protected]%3e >From Andreas Veithen ><[email protected]<mailto:[email protected]>> Subject Re: BackportUtil jar causing memory leak Date Tue, 16 Mar 2010 11:49:09 GMT On Tue, Mar 16, 2010 at 09:46, mohit sikri <[email protected]<mailto:[email protected]>> wrote: > > Hi Andreas/Axis Team, > > It is since which version of axis2. Since Axis2 1.5. > We are using axis2.1.4 and there seems to be a tight coupling between the > two(backport.jar and axis core(kernel)), isn't there any system parameter which can be configured or a way to configure axis2.xml so as to switch to concurrency framework provided by jdk5 rather than using backport.jar, by still maintaining the same version of axis. No. > Request you to provide any workaround if possible. > > > --- On Tue, 16/3/10, Andreas Veithen > <[email protected]<mailto:[email protected]>> wrote: > > From: Andreas Veithen <[email protected]> > Subject: Re: BackportUtil jar causing memory leak > To: [email protected] > Date: Tuesday, 16 March, 2010, 12:01 AM > > Since we moved to Java 1.5, Axis2 no longer relies on this library. > > On Mon, Mar 15, 2010 at 15:05, sri ram > <[email protected]<mailto:[email protected]>> wrote: > > Hi Axis2 Users, > > > > This is regarding the jar backport-util-concurrent.jar which is being used > > in Axis2 at some > > stage of processing the request .However the? hprof file shows a lot issues > > with this > > jar as? it consumes a lot of heap space and causing memory leak .Finally > > causing the tomcat to crash . > > Can anyone suggest the root cause of the issue or direct me to the > > improvised jar. > > This issue is critical. > > I can provide more info on this if required. > > > > Thanks, > > Sriram > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected]<mailto:[email protected]> For additional commands, e-mail: [email protected]<mailto:[email protected]> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected]<mailto:[email protected]> For additional commands, e-mail: [email protected]<mailto:[email protected]> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected]<mailto:[email protected]> For additional commands, e-mail: [email protected]<mailto:[email protected]> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected]<mailto:[email protected]> For additional commands, e-mail: [email protected]<mailto:[email protected]>
