[
https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13614456#comment-13614456
]
Rene Thomsen commented on AXIS2-3011:
-------------------------------------
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: [email protected]
For additional commands, e-mail: [email protected]
