axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rene Thomsen (JIRA)" <>
Subject [jira] [Commented] (AXIS2-3011) ServiceDescription caching leads to memory leak
Date Tue, 26 Mar 2013 19:25:15 GMT


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:

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:
>             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:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message