Return-Path: Delivered-To: apmail-lucene-hadoop-dev-archive@locus.apache.org Received: (qmail 58243 invoked from network); 22 Nov 2006 16:56:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 22 Nov 2006 16:56:25 -0000 Received: (qmail 35485 invoked by uid 500); 22 Nov 2006 16:56:34 -0000 Delivered-To: apmail-lucene-hadoop-dev-archive@lucene.apache.org Received: (qmail 35460 invoked by uid 500); 22 Nov 2006 16:56:34 -0000 Mailing-List: contact hadoop-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hadoop-dev@lucene.apache.org Delivered-To: mailing list hadoop-dev@lucene.apache.org Received: (qmail 35451 invoked by uid 99); 22 Nov 2006 16:56:34 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Nov 2006 08:56:34 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= 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; Wed, 22 Nov 2006 08:56:24 -0800 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id DF9807142C1 for ; Wed, 22 Nov 2006 08:56:03 -0800 (PST) Message-ID: <29830454.1164214563913.JavaMail.jira@brutus> Date: Wed, 22 Nov 2006 08:56:03 -0800 (PST) From: "Owen O'Malley (JIRA)" To: hadoop-dev@lucene.apache.org Subject: [jira] Commented: (HADOOP-639) task cleanup messages can get lost, causing task trackers to keep tasks forever In-Reply-To: <23380746.1161813796565.JavaMail.root@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ http://issues.apache.org/jira/browse/HADOOP-639?page=comments#action_12451988 ] Owen O'Malley commented on HADOOP-639: -------------------------------------- To clarify, the point of the type ids in the TaskTrackerActions is so that we can serialize the list of actions efficiently. I'd make TaskTrackerAction an abstract class like: abstract class TaskTrackerAction implements Writable { /** Get the type id for a type */ public abstract int getTypeId(); /** Create an instance of the appropriate child type. */ public static TaskTrackerAction newInstance(int typeId); } and then the children look like: class StartTaskAction extends TaskTrackerAction { int getTypeId() { return 1; } Task newTask; public void readFields(...) throws IOException {...} public void write(...) throws IOException {...} } KillTaskAction has a jobid and taskid. KillJobAction has a jobid. We also need a action to reinitialize the task tracker (ReinitializeSelfAction?). "JTResponse" is too information free. How about "TaskTrackerActionList" instead. I think we are better off using a boolean than a special value for ackNo. As a side effect we can use short for ackNo because it is ok if it rolls around. And taking a hint from linux, we are probably better starting at a -100 so that we wrap pretty soon after start up. *smile* > task cleanup messages can get lost, causing task trackers to keep tasks forever > ------------------------------------------------------------------------------- > > Key: HADOOP-639 > URL: http://issues.apache.org/jira/browse/HADOOP-639 > Project: Hadoop > Issue Type: Bug > Components: mapred > Affects Versions: 0.7.2 > Reporter: Owen O'Malley > Assigned To: Arun C Murthy > Fix For: 0.9.0 > > > If the pollForTaskWithClosedJob call from a job tracker to a task tracker times out when a job completes, the tasks are never cleaned up. This can cause the mini m/r cluster to hang on shutdown, but also is a resource leak. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira