Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 34624 invoked from network); 24 Jul 2007 22:00:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 24 Jul 2007 22:00:56 -0000 Received: (qmail 743 invoked by uid 500); 24 Jul 2007 22:00:56 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 674 invoked by uid 500); 24 Jul 2007 22:00:55 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 660 invoked by uid 99); 24 Jul 2007 22:00:55 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Jul 2007 15:00:55 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Jul 2007 15:00:53 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 22BBF714159 for ; Tue, 24 Jul 2007 15:00:31 -0700 (PDT) Message-ID: <7927699.1185314431132.JavaMail.jira@brutus> Date: Tue, 24 Jul 2007 15:00:31 -0700 (PDT) From: "Jarek Gawor (JIRA)" To: axis-dev@ws.apache.org Subject: [jira] Created: (AXIS2-3011) ServiceDescription caching leads to memory leak MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org ServiceDescription caching leads to memory leak ----------------------------------------------- Key: AXIS2-3011 URL: https://issues.apache.org/jira/browse/AXIS2-3011 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Jarek Gawor 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. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org For additional commands, e-mail: axis-dev-help@ws.apache.org