Mailing-List: contact java-dev-help@axis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@axis.apache.org
Date: Tue, 26 Mar 2013 19:25:15 +0000 (UTC)
From: "Rene Thomsen (JIRA)" <jira@apache.org>
To: java-dev@axis.apache.org
Message-ID: <JIRA.12374501.1185314375872.58627.1364325915958@arcas>
In-Reply-To: <JIRA.12374501.1185314375872@arcas>
References: <JIRA.12374501.1185314375872@arcas>
Subject: [jira] [Commented] (AXIS2-3011) ServiceDescription caching leads to
 memory leak
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org