hadoop-common-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Shvachko <...@yahoo-inc.com>
Subject Re: secondary namenode web interface
Date Tue, 08 Apr 2008 18:54:35 GMT
Yuri,

The NullPointerException should be fixed as Dhruba proposed.
We do not have any secondary nn web interface as of today.
The http server is used for transferring data between the primary and the secondary.
I don't see we can display anything useful on the secondary web UI except for the
current status, config values, and the last checkpoint date/time.
If you have anything in mind that can be displayed on the UI please let us know.
You can also find a jira for the issue, it would be good if this discussion
is reflected in it.

Thanks,
--Konstantin

dhruba Borthakur wrote:
> The secondary Namenode uses the HTTP interface to pull the fsimage from
> the primary. Similarly, the primary Namenode uses the
> dfs.secondary.http.address to pull the checkpointed-fsimage back from
> the secondary to the primary. So, the definition of
> dfs.secondary.http.address is needed.
> 
> However, the servlet dfshealth.jsp should not be served from the
> secondary Namenode. This servet should be setup in such a way that only
> the primary Namenode invokes this servlet.
> 
> Thanks,
> dhruba
> 
> -----Original Message-----
> From: Yuri Pradkin [mailto:yuri@isi.edu] 
> Sent: Tuesday, April 08, 2008 10:11 AM
> To: core-user@hadoop.apache.org
> Subject: Re: secondary namenode web interface
> 
> I'd be happy to file a JIRA for the bug, I just want to make sure I
> understand 
> what the bug is: is it the misleading "null pointer" message or is it
> that 
> someone is listening on this port and not doing anything useful?  I
> mean,
> what is the configuration parameter dfs.secondary.http.address for?
> Unless 
> there are plans to make this interface work, this config parameter
> should go 
> away, and so should the listening thread, shouldn't they?
> 
> Thanks,
>   -Yuri
> 
> On Friday 04 April 2008 03:30:46 pm dhruba Borthakur wrote:
> 
>>Your configuration is good. The secondary Namenode does not publish a
>>web interface. The "null pointer" message in the secondary Namenode
> 
> log
> 
>>is a harmless bug but should be fixed. It would be nice if you can
> 
> open
> 
>>a JIRA for it.
>>
>>Thanks,
>>Dhruba
>>
>>
>>-----Original Message-----
>>From: Yuri Pradkin [mailto:yuri@isi.edu]
>>Sent: Friday, April 04, 2008 2:45 PM
>>To: core-user@hadoop.apache.org
>>Subject: Re: secondary namenode web interface
>>
>>I'm re-posting this in hope that someone would help.  Thanks!
>>
>>On Wednesday 02 April 2008 01:29:45 pm Yuri Pradkin wrote:
>>
>>>Hi,
>>>
>>>I'm running Hadoop (latest snapshot) on several machines and in our
>>
>>setup
>>
>>
>>>namenode and secondarynamenode are on different systems.  I see from
>>
>>the
>>
>>
>>>logs than secondary namenode regularly checkpoints fs from primary
>>>namenode.
>>>
>>>But when I go to the secondary namenode HTTP
>>
>>(dfs.secondary.http.address)
>>
>>
>>>in my browser I see something like this:
>>>
>>>	HTTP ERROR: 500
>>>	init
>>>	RequestURI=/dfshealth.jsp
>>>	Powered by Jetty://
>>>
>>>And in secondary's log I find these lines:
>>>
>>>2008-04-02 11:26:25,357 WARN /: /dfshealth.jsp:
>>>java.lang.NullPointerException
>>>        at
>>>org.apache.hadoop.dfs.dfshealth_jsp.<init>(dfshealth_jsp.java:21) at
>>>sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> 
> Method)
> 
>>at
>>
>>
> 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorA
> 
>>cce
>>
>>
>>>ssorImpl.java:57) at
>>
>>
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons
> 
>>tru
>>
>>
>>>ctorAccessorImpl.java:45) at
>>>java.lang.reflect.Constructor.newInstance(Constructor.java:539) at
>>>java.lang.Class.newInstance0(Class.java:373)
>>>        at java.lang.Class.newInstance(Class.java:326)
>>>        at
>>
>>org.mortbay.jetty.servlet.Holder.newInstance(Holder.java:199)
>>
>>
>>>        at
>>
>>
> org.mortbay.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:32
> 
>>6)
>>
>>
>>>at
>>
>>org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:405)
>>
>>
>>>at
>>
>>
> org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationH
> 
>>and
>>
>>
>>>ler.java:475) at
>>
>>
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
> 
>>at
>>
>>
>>>org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at
>>
>>
> org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationCon
> 
>>tex
>>
>>
>>>t.java:635) at
>>
>>org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at
>>
>>
>>>org.mortbay.http.HttpServer.service(HttpServer.java:954) at
>>>org.mortbay.http.HttpConnection.service(HttpConnection.java:814) at
>>>org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:981)
> 
> at
> 
>>>org.mortbay.http.HttpConnection.handle(HttpConnection.java:831) at
>>
>>
> org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244
> 
>>)
>>
>>
>>>at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
> 
> at
> 
>>>org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
>>>
>>>Is something missing from my configuration?  Anybody else seen
> 
> these?
> 
>>>Thanks,
>>>
>>>  -Yuri
> 
> 
> 
> 

Mime
View raw message