Hello Amila, thanks for your information. Are you sure that the bug is fixed already? I have found an resolved issue in Axis2 JIRA (http://issues.apache.org/jira/browse/AXIS2-3870), but the comments of other users state that the bug is not fixed. Can anybody confirm that the bug is really fixed?
If I would use Axis2 1.5- Is it necessary to regenerate the client for AXIS2 1.5? We have generated it with Axis2 1.4... Thanks, Jens Amila Suriarachchi wrote: > > Can you try with Axis2 1.5? There was a memory leak in 1.4 and fixed for > 1.5. > > thanks, > Amila. > > On Fri, Nov 20, 2009 at 5:20 PM, Jens Goldhammer < > goldhammer...@googlemail.com> wrote: > >> >> Hello together, >> >> We are using Axis2 1.4 as ws-client framework in a web application >> (deployed >> in JBOSS) and have encountered a problem after making the >> Axis2ConfigurationContext a singleton. >> >> This approach was necessary because creating the configurationcontext >> needs >> a lot of time and we don´t want to do it again and again... This was the >> suggestion in a discussion on the mailing list of Axis2 >> ( >> http://markmail.org/message/57afv4yi3t76b7nk#query:+page:1+mid:57afv4yi3t76b7nk+state:results >> ) >> >> So Iimplemented a static method which provides the configurationContext >> to >> the caller. If the configurationcontext is created one time, we save it >> in >> a >> static variable and use this in later calls. >> >> /** >> * reuse the configuration context of AXIS2 because it is expensive to >> create a new one every time you create a >> * client stub. For more information look at url: >> * >> >> http://markmail.org/message/57afv4yi3t76b7nk#query:+page:1+mid:57afv4yi3t76b7nk+state:results >> * >> * @return a valid configuration context for the axis2 stubs >> * @throws AxisFault if creating the configuration context fails. >> */ >> static synchronized ConfigurationContext getConfigurationContext() >> throws AxisFault { >> if (configCtx == null) { >> >> ClassLoader tccl = >> Thread.currentThread().getContextClassLoader(); >> try { >> // set local ClassLoader >> ClassLoader bofModuleClassLoader = >> RPlanWebServiceHelper.class.getClassLoader(); >> >> Thread.currentThread().setContextClassLoader(bofModuleClassLoader); >> >> configCtx = >> ConfigurationContextFactory.createConfigurationContextFromFileSystem(null, >> null); >> >> } finally { >> // restore thread context ClassLoader >> Thread.currentThread().setContextClassLoader(tccl); >> } >> } >> >> return configCtx; >> } >> >> The client stubs are created the following way: >> >> ProjectServiceStub projectServiceStub = new >> ProjectServiceStub(getConfigurationContext(), projectServiceUrl); >> projectServiceStub.UpdateSchedule(updateScheduleType); >> >> After some days we realized that there are very often out of memory >> errors >> in that application. The application is a so called method server which >> runs >> several jobs which are doing a lot of work with the axis2 client. >> >> We analyzed the headdump of the java process and determine that the >> axis2configuration instance needs a lot of memory at the time of the out >> of >> memory error. See the attached file for more information. The hashtable >> instance of allEndpoints is about 200 Megabyte. >> >> Please help me to find the problem? Is there a problem how we use the >> configuration context or is this a bug in Axis2? >> >> Thanks, >> Jens >> >> http://old.nabble.com/file/p26440452/headdump_analysis.html >> headdump_analysis.html >> >> -- >> View this message in context: >> http://old.nabble.com/Resuse-of-configurationcontext-ends-in-out-of-memory-error-tp26440452p26440452.html >> Sent from the Axis - User mailing list archive at Nabble.com. >> >> > > > -- > Amila Suriarachchi > WSO2 Inc. > blog: http://amilachinthaka.blogspot.com/ > > -- View this message in context: http://old.nabble.com/Resuse-of-configurationcontext-ends-in-out-of-memory-error-tp26442083p26495216.html Sent from the Axis - User mailing list archive at Nabble.com.
