You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Rene Thomsen (JIRA)" <ji...@apache.org> on 2013/03/26 20:35:15 UTC
[jira] [Comment Edited] (AXIS2-3011) ServiceDescription caching
leads to memory leak
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13614456#comment-13614456 ]
Rene Thomsen edited comment on AXIS2-3011 at 3/26/13 7:33 PM:
--------------------------------------------------------------
sry to bother after all this time.
we have a similar issue in axis 1.6.2.
ive created an issue here: https://issues.apache.org/jira/browse/AXIS2-5504
HA:
Leak suspect 438.996.887 bytes (35,12 %) of Java heap is used by 276 instances of java/util/Hashtable$Entry
Total size 438.996.887 bytes
Size 6.136 bytes
Name array of [Ljava/util/Hashtable$Entry;
Number of children 276
Number of parents 1
Owner address 0x2aaaf0b04720
Owner object java/util/Hashtable
Address 0x2aab0bdd76b0
First single ancestor class org/apache/axis2/jaxws/description/impl/DescriptionFactoryImpl at 0x2aab0bdd76b0
as i understand it this factory takes care of the description of each service in a servicegroup. we only have 1 service.
can anyone please help in explaining how the DescriptionFactoryImpl can grow to this size?
we have peaks with high loads.... but not too serious. however the response time is sometime high which hold the resource in the factory i assume.
all i can find on the net is that this can happen when you have a lot of services, we have only one. :-)
was (Author: reth):
sry to bother after all this time.
we have a similar issue in axis 1.6.2.
ive created an issue here: https://issues.apache.org/jira/browse/AXIS2-5504
HA:
Leak suspect 438.996.887 bytes (35,12 %) of Java heap is used by 276 instances of java/util/Hashtable$Entry
Total size 438.996.887 bytes
Size 6.136 bytes
Name array of [Ljava/util/Hashtable$Entry;
Number of children 276
Number of parents 1
Owner address 0x2aaaf0b04720
Owner object java/util/Hashtable
Address 0x2aab0bdd76b0
First single ancestor class org/apache/axis2/jaxws/description/impl/DescriptionFactoryImpl at 0x2aab0bdd76b0
as i understand it this factory takes care of the description of each service in a servicegroup. we only have 1 service.
can anyone please help in explaining how the DescriptionFactoryImpl can grow to this size?
it happens very slowly over a few weeks... 6-10 request a sec.
all i can find on the net is that this can happen when you have about 250 services we have only one.
> ServiceDescription caching leads to memory leak
> -----------------------------------------------
>
> Key: AXIS2-3011
> URL: https://issues.apache.org/jira/browse/AXIS2-3011
> Project: Axis2
> Issue Type: Bug
> Components: jaxws
> Reporter: Jarek Gawor
> Assignee: Ann Robinson
> Attachments: AXIS2-3011-a.patch, AXIS2-3011.patch
>
>
> The DescriptionFactoryImpl.createServiceDescription() function attempts to cache/reuse the ServiceDescription objects and that leads to memory leaks.
> First, a Hashtable is used for the cache. That means, any ServiceDescription created will always live in the cache and won't ever be reclaimed (and there is no clear cache function). Some sort of WeakHashMap could help the problem so that at least some unused ServiceDescription objects could be reclaimed.
> Second, the createServiceDescription() uses the DescriptionFactory.createClientConfigurationFactory().getClientConfigurationContext() to get the client configuration context. It looks like by default the ClientConfigurationFactory.getClientConfigurationContext() does NOT cache the configuration context. Therefore, each call creates a new configuration object. That means, that by default ServiceDescription will NOT be reused since the configuration context object instance is used to determine if the ServiceDescription should be reused or not (see DescriptionKey.equals() function).
> So, a simple program that calls createServiceDescription() repeatably in a loop (with the same arguments) will quickly run out of memory.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org