Return-Path: X-Original-To: apmail-hadoop-common-issues-archive@minotaur.apache.org Delivered-To: apmail-hadoop-common-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 277149D0C for ; Thu, 23 Aug 2012 09:23:45 +0000 (UTC) Received: (qmail 71842 invoked by uid 500); 23 Aug 2012 09:23:44 -0000 Delivered-To: apmail-hadoop-common-issues-archive@hadoop.apache.org Received: (qmail 71638 invoked by uid 500); 23 Aug 2012 09:23:44 -0000 Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: common-issues@hadoop.apache.org Delivered-To: mailing list common-issues@hadoop.apache.org Received: (qmail 71237 invoked by uid 99); 23 Aug 2012 09:23:43 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Aug 2012 09:23:43 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id EA7F62C0912 for ; Thu, 23 Aug 2012 09:23:42 +0000 (UTC) Date: Thu, 23 Aug 2012 20:23:42 +1100 (NCT) From: "Hadoop QA (JIRA)" To: common-issues@hadoop.apache.org Message-ID: <1540570302.4756.1345713822961.JavaMail.jiratomcat@arcas> In-Reply-To: <1205435518.116104.1343657854639.JavaMail.jiratomcat@issues-vm> Subject: [jira] [Commented] (HADOOP-8632) Configuration leaking class-loaders MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HADOOP-8632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440172#comment-13440172 ] Hadoop QA commented on HADOOP-8632: ----------------------------------- +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12542100/HADOOP-8632-trunk-no-tabs.patch against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 1 new or modified test files. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 javadoc. The javadoc tool did not generate any warning messages. +1 eclipse:eclipse. The patch built with eclipse:eclipse. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed unit tests in hadoop-common-project/hadoop-common. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/1351//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/1351//console This message is automatically generated. > Configuration leaking class-loaders > ----------------------------------- > > Key: HADOOP-8632 > URL: https://issues.apache.org/jira/browse/HADOOP-8632 > Project: Hadoop Common > Issue Type: Bug > Components: conf > Affects Versions: 2.0.0-alpha > Reporter: Costin Leau > Attachments: 0001-wrapping-classes-with-WeakRefs-in-CLASS_CACHE.patch, HADOOP-8632.patch, HADOOP-8632-trunk-no-tabs.patch, HADOOP-8632-trunk.patch > > > The newly introduced CACHE_CLASSES leaks class loaders causing associated classes to not be reclaimed. > One solution is to remove the cache itself since each class loader implementation caches the classes it loads automatically and preventing an exception from being raised is just a micro-optimization that, as one can tell, causes bugs instead of improving anything. > In fact, I would argue in a highly-concurrent environment, the weakhashmap synchronization/lookup probably costs more then creating the exception itself. > Another is to prevent the leak from occurring, by inserting the loadedclass into the WeakHashMap wrapped in a WeakReference. Otherwise the class has a strong reference to its classloader (the key) meaning neither gets GC'ed. > And since the cache_class is static, even if the originating Configuration instance gets GC'ed, its classloader won't. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira