Return-Path: Delivered-To: apmail-lucene-hadoop-dev-archive@locus.apache.org Received: (qmail 89912 invoked from network); 27 Dec 2007 09:03:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 Dec 2007 09:03:07 -0000 Received: (qmail 65926 invoked by uid 500); 27 Dec 2007 09:02:55 -0000 Delivered-To: apmail-lucene-hadoop-dev-archive@lucene.apache.org Received: (qmail 65888 invoked by uid 500); 27 Dec 2007 09:02:55 -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 65879 invoked by uid 99); 27 Dec 2007 09:02:55 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Dec 2007 01:02:55 -0800 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; Thu, 27 Dec 2007 09:02:51 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 104EB714204 for ; Thu, 27 Dec 2007 01:02:43 -0800 (PST) Message-ID: <27351429.1198746163063.JavaMail.jira@brutus> Date: Thu, 27 Dec 2007 01:02:43 -0800 (PST) From: "Devaraj Das (JIRA)" To: hadoop-dev@lucene.apache.org Subject: [jira] Updated: (HADOOP-2404) HADOOP-2185 breaks compatibility with hadoop-0.15.0 In-Reply-To: <22781223.1197372523409.JavaMail.jira@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 [ https://issues.apache.org/jira/browse/HADOOP-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Devaraj Das updated HADOOP-2404: -------------------------------- Status: Open (was: Patch Available) There is one problem that HADOOP-2185 introduced (without knowledge I am sure) in the tasktracker's reinitialization (after the jobtracker declares the tasktracker as lost, and upon the next connection to the jobtracker, the tasktracker is asked to reinitialize). Post HADOOP-2185, the tasktracker's initialize method sets "mapred.task.tracker.report.bindAddress" to the listener address. This would be in the format _/:_ (due to the way InetAddress.toString() is implemented). Now if the tasktracker were lost and were to reinitialize, it would call the initialize method again, and this time the call to createSocketAddress would fail because of the leading slash in the argument, and the tasktracker would not be able to recover from this. So maybe, we should do a check for '/' in the tasktracker initialization before passing it to createSocketAddress? Not sure whether such problems exist elsewhere in the framework code too .... Pre-HADOOP-2185, the "mapred.task.tracker.report.bindAddress" would not be reset to the listener address, and, hence the above problem is not there.. This issue needs a resolution (and hence I am cancelling the patch). > HADOOP-2185 breaks compatibility with hadoop-0.15.0 > --------------------------------------------------- > > Key: HADOOP-2404 > URL: https://issues.apache.org/jira/browse/HADOOP-2404 > Project: Hadoop > Issue Type: Bug > Components: conf > Affects Versions: 0.16.0 > Reporter: Arun C Murthy > Assignee: Konstantin Shvachko > Priority: Blocker > Fix For: 0.16.0 > > Attachments: ConfigConvert.patch, ConfigurationConverter.patch > > > HADOOP-2185 removed the following configuration parameters: > {noformat} > dfs.secondary.info.port > dfs.datanode.port > dfs.info.port > mapred.job.tracker.info.port > tasktracker.http.port > {noformat} > and changed the following configuration parameters: > {noformat} > dfs.secondary.info.bindAddress > dfs.datanode.bindAddress > dfs.info.bindAddress > mapred.job.tracker.info.bindAddress > mapred.task.tracker.report.bindAddress > tasktracker.http.bindAddress > {noformat} > without a backward-compatibility story. > Lots are applications/cluster-configurations are prone to fail hence, we need a way to keep things working as-is for 0.16.0 and remove them for 0.17.0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.