Return-Path: Delivered-To: apmail-hadoop-mapreduce-dev-archive@minotaur.apache.org Received: (qmail 5967 invoked from network); 1 Jul 2010 21:58:48 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Jul 2010 21:58:48 -0000 Received: (qmail 85483 invoked by uid 500); 1 Jul 2010 21:58:48 -0000 Delivered-To: apmail-hadoop-mapreduce-dev-archive@hadoop.apache.org Received: (qmail 85225 invoked by uid 500); 1 Jul 2010 21:58:47 -0000 Mailing-List: contact mapreduce-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: mapreduce-dev@hadoop.apache.org Delivered-To: mailing list mapreduce-dev@hadoop.apache.org Received: (qmail 85204 invoked by uid 99); 1 Jul 2010 21:58:47 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Jul 2010 21:58:47 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Jul 2010 21:58:44 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o61LoqMP002584 for ; Thu, 1 Jul 2010 21:50:52 GMT Message-ID: <14769398.162621278021052700.JavaMail.jira@thor> Date: Thu, 1 Jul 2010 17:50:52 -0400 (EDT) From: "Dick King (JIRA)" To: mapreduce-dev@hadoop.apache.org Subject: [jira] Created: (MAPREDUCE-1909) TrackerDistributedCacheManager takes a blocking lock fo a loop that executes 10K times MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org TrackerDistributedCacheManager takes a blocking lock fo a loop that executes 10K times -------------------------------------------------------------------------------------- Key: MAPREDUCE-1909 URL: https://issues.apache.org/jira/browse/MAPREDUCE-1909 Project: Hadoop Map/Reduce Issue Type: Improvement Reporter: Dick King Assignee: Dick King In {{TrackerDistributedCachaManager.java}} , the portion where the cache is cleaned up, the lock is taken on the main hash table and then all the entries are scanned to see if they can be deleted. That's a long lockage. The table is likely to have 10K entries. I would like to reduce the longest lock duration by maintaining the set of {{CacheStatus}} es to delete incrementally. 1: Let there be a new {{HashSet}}, {{deleteSet}}, that's protected under {{synchronized(cachedArchives)}} 2: When {{refcount}} is decreased to 0, move the {{CacheStatus}} from {{cachedArchives}} to {{deleteSet}} 3: When seeking an existing {{CacheStatus}}, look in {{deleteSet}} if it isn't in {{cachedArchives}} 4: When {{refcount}} is increased from 0 to 1 in a pre-existing {{CacheStatus}} [see 3:, above] move the {{CacheStatus}} from {{deleteSet}} to {{cachedArchives}} 5: When we clean the cache, under {{synchronized(cachedArchives)}} , move {{deleteSet}} to a local variable and create a new empty {{HashSet}}. This is constant time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.