Re: Resuse of configurationcontext ends in out of memory error
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.
Resuse of configurationcontext ends in out of memory error
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/p26438102/headdump_analysis.html
headdump_analysis.html
--
View this message in context:
http://old.nabble.com/Resuse-of-configurationcontext-ends-in-out-of-memory-error-tp26438102p26438102.html
Sent from the Axis - User mailing list archive at Nabble.com.
Resuse of configurationcontext ends in out of memory error
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.
Re: Resuse of configurationcontext ends in out of memory error
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/
