[
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: [email protected]
For additional commands, e-mail: [email protected]
