Return-Path: Delivered-To: apmail-cxf-dev-archive@www.apache.org Received: (qmail 43229 invoked from network); 1 Jun 2008 01:50:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Jun 2008 01:50:32 -0000 Received: (qmail 71793 invoked by uid 500); 1 Jun 2008 01:50:34 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 71741 invoked by uid 500); 1 Jun 2008 01:50:34 -0000 Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list dev@cxf.apache.org Received: (qmail 71730 invoked by uid 99); 1 Jun 2008 01:50:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 31 May 2008 18:50:34 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [64.79.199.57] (HELO server.dankulp.com) (64.79.199.57) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Jun 2008 01:49:43 +0000 Received: by server.dankulp.com (Postfix, from userid 5000) id 9ECAB197C080; Sat, 31 May 2008 21:49:59 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on server.dankulp.com X-Spam-Level: X-Msg-File: /tmp/mailfilter.DOWmv2nMOS Received: from [192.168.1.105] (c-24-147-10-180.hsd1.ma.comcast.net [24.147.10.180]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by server.dankulp.com (Postfix) with ESMTP id A9783197C023 for ; Sat, 31 May 2008 21:49:58 -0400 (EDT) Message-Id: <865D7BD6-5FCA-4065-994F-2005D3BB4AD3@apache.org> From: Daniel Kulp To: dev@cxf.apache.org In-Reply-To: <5dc0f8d50805311355l26aaa9bas2c966add9d2fc46f@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Subject: Re: Memory Leak at WSDLManagerImpl Date: Sat, 31 May 2008 21:49:57 -0400 References: <5dc0f8d50805311355l26aaa9bas2c966add9d2fc46f@mail.gmail.com> X-Mailer: Apple Mail (2.924) X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No, score=0.3 required=3.0 tests=BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.4 Hmmm.... good sleuthing. You definitely don't want to unregister it on endpoint stop or when done with the client. The whole point of the cache is to hold onto it so it's reusable. On popular thing to do is create a client, use it once, discard. Create another client, use it once, discard. Etc... The cache is to help that. I think what might make some sense is to get rid of the schemaCacheMap entirely. Change the definitionsMap to be a Map map where DepPair holds a wsdldef and the schema. Thus, the keys would be the same keys for the wsdl. The put/set's would be more expensive as you would need to iterate through the cache to find the pair. I doubt the map would be very big though so that may be acceptable. Dan On May 31, 2008, at 4:55 PM, Bharath Ganesh wrote: > I figured out a memory leak at WSDLManagerImpl schemaCacheMap. > The schemaCacheMap here has a weak key - WSDLDefinition and value > ServiceSchemaInfo. A key,value pair is inserted into this map while > building > a service. The entry is never explicitly removed from this map. > Since the > map is a WeakHashMap, it is assumed that when the key WSDLDefinition > is > weakly referenced, the entry would be removed from the map. But it > is seen > that the value ServiceSchemaInfo(the value) holds on to a SchemaInfo > which > in turn holds on to the ServiceInfo, which holds the WSDLDefinition > through > the AbstractPropertiesHolder. > This would mean that the value of the CacheMap always strongly > refers to the > key, which would mean the entry would never be removed from the map. > "*The value objects in a WeakHashMap are held by ordinary strong > references. > Thus care should be taken to ensure that value objects do not > strongly refer > to their own keys, either directly or indirectly, since that will > prevent > the keys from being discarded" > > *This would mean ServiceInfo, OperationInfo, BindingInfo, > WSDLDefinition > would all stay in the VM even after the endpoint is stopped. > > One solution I could think of was to explicitly remove the entry on > endpoint > stop, instead of relying on the WeakHashMap semantics. This would > work fine > for server endpoints. But Is there any way to do so for client > endpoints? --- Daniel Kulp dkulp@apache.org http://www.dankulp.com/blog