Return-Path: 
 <common-user-return-18432-apmail-hadoop-common-user-archive=hadoop.apache.org@hadoop.apache.org>
Delivered-To: apmail-hadoop-common-user-archive@www.apache.org
Received: (qmail 55310 invoked from network); 2 Nov 2009 15:50:51 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 2 Nov 2009 15:50:51 -0000
Received: (qmail 90169 invoked by uid 500); 2 Nov 2009 15:50:48 -0000
Delivered-To: apmail-hadoop-common-user-archive@hadoop.apache.org
Received: (qmail 90100 invoked by uid 500); 2 Nov 2009 15:50:47 -0000
Mailing-List: contact common-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:common-user-help@hadoop.apache.org>
List-Unsubscribe: <mailto:common-user-unsubscribe@hadoop.apache.org>
List-Post: <mailto:common-user@hadoop.apache.org>
List-Id: <common-user.hadoop.apache.org>
Reply-To: common-user@hadoop.apache.org
Delivered-To: mailing list common-user@hadoop.apache.org
Received: (qmail 90085 invoked by uid 99); 2 Nov 2009 15:50:47 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Nov 2009 15:50:47 +0000
X-ASF-Spam-Status: No, hits=-6.0 required=5.0
	tests=AWL,BAYES_00,RCVD_IN_DNSWL_MED
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of awittenauer@linkedin.com
 designates 69.28.149.25 as permitted sender)
Received: from [69.28.149.25] (HELO esv4-mav03.corp.linkedin.com)
 (69.28.149.25)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Nov 2009 15:50:45 +0000
DomainKey-Signature: s=prod; d=linkedin.com; c=nofws; q=dns;
  h=X-IronPort-AV:Received:User-Agent:Date:Subject:From:To:
   Message-ID:Thread-Topic:Thread-Index:In-Reply-To:
   Mime-version:Content-type:Content-transfer-encoding;
  b=kBGvNPFI+8WQvdwmYUGPuMjRkYVHA1T+rRrRrFLfU09iuPAINcJiMy+3
   r+Ab5m00804W8XUEIhmMlm8EFC5JOJBRjjGmIZA8qGCtMm7rT+l7WOnUj
   EeTgpYrh2H8+Wsn;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
  d=linkedin.com; i=awittenauer@linkedin.com; q=dns/txt;
  s=proddkim; t=1257177045; x=1288713045;
  h=from:sender:reply-to:subject:date:message-id:to:cc:
   mime-version:content-transfer-encoding:content-id:
   content-description:resent-date:resent-from:resent-sender:
   resent-to:resent-cc:resent-message-id:in-reply-to:
   references:list-id:list-help:list-unsubscribe:
   list-subscribe:list-post:list-owner:list-archive;
  z=From:=20Allen=20Wittenauer=20<awittenauer@linkedin.com>
   |Subject:=20Re:=20dfs=20health=20Dashboard|Date:=20Mon,
   =2002=20Nov=202009=2007:50:23=20-0800|Message-ID:=20<C714
   3FBF.1213%awittenauer@linkedin.com>|To:=20<common-user@ha
   doop.apache.org>|Mime-version:=201.0
   |Content-transfer-encoding:=207bit|In-Reply-To:=20<4AEE78
   0C.1090907@mkhoj.com>;
  bh=eLEeZfrJ5DZFFOs1kEBwr008725to0zE+elRbDukW+I=;
  b=vjxWObi6cn5xi7o2Oqi+w/crsrD9j+PWtlUWiRHFu/YovMsqaXy1jZGq
   rDyWt9uql0sjJ0u3cP3fh0pyGcO2GRJ7sFNRekuC8CdYWZ+IteHBjLUTK
   eo5krva9H5DWX0I;
X-IronPort-AV: E=Sophos;i="4.44,667,1249282800";
   d="scan'208";a="9292097"
Received: from 172.18.36.48 ([172.18.36.48]) by CORP-MAIL.linkedin.biz
 ([172.18.46.135]) via Exchange Front-End Server mail-access.linkedin.biz
 ([172.18.46.133]) with Microsoft Exchange Server HTTP-DAV ;
 Mon,  2 Nov 2009 15:50:24 +0000
User-Agent: Microsoft-Entourage/12.10.0.080409
Date: Mon, 02 Nov 2009 07:50:23 -0800
Subject: Re: dfs health Dashboard
From: Allen Wittenauer <awittenauer@linkedin.com>
To: <common-user@hadoop.apache.org>
Message-ID: <C7143FBF.1213%awittenauer@linkedin.com>
Thread-Topic: dfs health Dashboard
Thread-Index: Acpb1DAA3Rt7MOyU/ECK4XqJUoHgnA==
In-Reply-To: <4AEE780C.1090907@mkhoj.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit




On 11/1/09 10:11 PM, "V Satish Kumar" <satish.kumar@mkhoj.com> wrote:
> I have noticed that the dfs health dashboard(Running on port  50070)
> takes a long time to refresh the number of live nodes and dead nodes. Is
> there a config parameter in hadoop that can be changed to make the
> dashboard shows these changes more quickly?

What do you mean by "long time"?  Hours? Days?

Keep in mind that you don't want a failure to be "instantaneous" because
that means every time there is even a minor, temporary blip the namenode and
the network will be busy replicating blocks that are just going to re-appear
in a minute or so anyway.