Re: Browse the filesystem weblink broken after upgrade to 1.0.0: HTTP 404 Problem accessing /browseDirectory.jsp

2012-03-01 Thread madhu phatak
On Wed, Feb 29, 2012 at 11:34 PM, W.P. McNeill bill...@gmail.com wrote:

 I can do perform HDFS operations from the command line like hadoop fs -ls
 /. Doesn't that meant that the datanode is up?


  No. It is just meta data lookup which comes from Namenode. Try to cat
some file like hadoop fs -cat  . Then if you are able get data then
datanode should be up . Also make sure that hdfs is not in safemode . To
turnoff safemode use hdfs command hadoop dfsadmin -safemode leave and
then restart the jobtracker and tasktracker.



-- 
Join me at http://hadoopworkshop.eventbrite.com/


Re: Browse the filesystem weblink broken after upgrade to 1.0.0: HTTP 404 Problem accessing /browseDirectory.jsp

2012-02-29 Thread W.P. McNeill
I can do perform HDFS operations from the command line like hadoop fs -ls
/. Doesn't that meant that the datanode is up?


Re: Browse the filesystem weblink broken after upgrade to 1.0.0: HTTP 404 Problem accessing /browseDirectory.jsp

2012-02-28 Thread madhu phatak
Hi,
 Just make sure that Datanode is up. Looking into the datanode logs.

On Sun, Feb 19, 2012 at 10:52 PM, W.P. McNeill bill...@gmail.com wrote:

 I am running in pseudo-distributed on my Mac and just upgraded from
 0.20.203.0 to 1.0.0. The web interface for HDFS which was working in
 0.20.203.0 is broken in 1.0.0.

 HDFS itself appears to work: a command line like hadoop fs -ls / returns
 a result, and the namenode web interface at http://
 http://localhost:50070/dfshealth.jsp comes up. However, when I click on
 the
 Browse the filesystem link on this page I get a 404 Error. The error
 message displayed in the browser reads:

 Problem accessing /browseDirectory.jsp. Reason:
/browseDirectory.jsp

 The URL in the browser bar at this point is 
 http://0.0.0.0:50070/browseDirectory.jsp?namenodeInfoPort=50070dir=/;.
 The
 HTML source to the link on the main namenode page is a
 href=/nn_browsedfscontent.jspBrowse the filesystem/a. If I change the
 server location from 0.0.0.0 to localhost in my browser bar I get the same
 error.

 I updated my configuration files in the new hadoop 1.0.0 conf directory to
 transfer over my settings from 0.20.203.0. My conf/slaves file consists of
 the line localhost.  I ran hadoop-daemon.sh start namenode -upgrade
 once when prompted my errors in the namenode logs. After that all the
 namenode and datanode logs contain no errors.

 For what it's worth, I've verified that the bug occurs on Firefox, Chrome,
 and Safari.

 Any ideas on what is wrong or how I should go about further debugging it?




-- 
Join me at http://hadoopworkshop.eventbrite.com/


Browse the filesystem weblink broken after upgrade to 1.0.0: HTTP 404 Problem accessing /browseDirectory.jsp

2012-02-19 Thread W.P. McNeill
I am running in pseudo-distributed on my Mac and just upgraded from
0.20.203.0 to 1.0.0. The web interface for HDFS which was working in
0.20.203.0 is broken in 1.0.0.

HDFS itself appears to work: a command line like hadoop fs -ls / returns
a result, and the namenode web interface at http://
http://localhost:50070/dfshealth.jsp comes up. However, when I click on the
Browse the filesystem link on this page I get a 404 Error. The error
message displayed in the browser reads:

Problem accessing /browseDirectory.jsp. Reason:
/browseDirectory.jsp

The URL in the browser bar at this point is 
http://0.0.0.0:50070/browseDirectory.jsp?namenodeInfoPort=50070dir=/;. The
HTML source to the link on the main namenode page is a
href=/nn_browsedfscontent.jspBrowse the filesystem/a. If I change the
server location from 0.0.0.0 to localhost in my browser bar I get the same
error.

I updated my configuration files in the new hadoop 1.0.0 conf directory to
transfer over my settings from 0.20.203.0. My conf/slaves file consists of
the line localhost.  I ran hadoop-daemon.sh start namenode -upgrade
once when prompted my errors in the namenode logs. After that all the
namenode and datanode logs contain no errors.

For what it's worth, I've verified that the bug occurs on Firefox, Chrome,
and Safari.

Any ideas on what is wrong or how I should go about further debugging it?