hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wilfred Spiegelenburg (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-4858) HDFS DataNode to NameNode RPC should timeout
Date Sun, 09 Feb 2014 23:04:22 GMT

    [ https://issues.apache.org/jira/browse/HDFS-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896092#comment-13896092

Wilfred Spiegelenburg commented on HDFS-4858:

>I thought the client timeout problem was solved by HDFS-4646. It's been working fine for
us since then. Is it a different problem you are talking about?

There are other parts of the code that use the ipc client. It is not just limited to the datanode.
The tasktracker, as mentioned is one example for MR1. The fact that the client does not timeout
for a write is still there. You now need to find every single place where you use the client
and make sure that you fix it. I tried to point that out.
Instead of pulling the time out for writes out of the client code (Client.java) it should
be handled transparently for the caller in the Client code. 

>> see around line 600
>Line 600 of what?

Line 600 of the Client.java code, If rpcTimeout is not set (0 or -1) then the pingInterval
will be used to make sure that the read times out. A similar construct should also be used
for the write side to make sure that you do not have  rpcTimeout set. The solution maintains
a different behaviour for read and write timeouts while this would be a chance to fix that.

>> It is also used by the TaskTracker
> Are you referring to cdh4, as trunk and Hadoop 2 don't have TaskTracker.

The TaskTracker was used as an example. Purely used to point to the fact that there are, or
could be, more users of the client code that exhibit the same issue.

>Sorry, I didn't understand the general problem from your descriptions, guys. If you could
tell how to reproduce it or better propose a fix. The DataNode problem is real though, because
fail-overs fail when the DN thread gets stuck. It would be good to fix it in the next release.

The issue is real for each user of the client code. Write on a socket does not time out (normal
behaviour). When a hardware failure occurs on a network layer this becomes apparent (unplug
a cable, server HW failure, switch failure etc). Steps to reproduce are given in this bug
and in HDFS-4646. They all work. TCP timeout and retry are the underlying cause of this 'hang'
and faster fails can be achieved by changing the tcp_retries2 parameter at the kernel level.
Instead of looking outside the Client.java code why do we not time out the write itself? Currently
the code just waits forever for the write to return, a simple change would be to change that
wait. I can attach a diff for the change if that makes it easier to see what I mean.

> HDFS DataNode to NameNode RPC should timeout
> --------------------------------------------
>                 Key: HDFS-4858
>                 URL: https://issues.apache.org/jira/browse/HDFS-4858
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: datanode
>    Affects Versions: 3.0.0, 2.1.0-beta, 2.0.4-alpha, 2.0.5-alpha
>         Environment: Redhat/CentOS 6.4 64 bit Linux
>            Reporter: Jagane Sundar
>            Assignee: Konstantin Boudnik
>            Priority: Minor
>             Fix For: 3.0.0, 2.3.0
>         Attachments: HDFS-4858.patch, HDFS-4858.patch
> The DataNode is configured with ipc.client.ping false and ipc.ping.interval 14000. This
configuration means that the IPC Client (DataNode, in this case) should timeout in 14000 seconds
if the Standby NameNode does not respond to a sendHeartbeat.
> What we observe is this: If the Standby NameNode happens to reboot for any reason, the
DataNodes that are heartbeating to this Standby get stuck forever while trying to sendHeartbeat.
See Stack trace included below. When the Standby NameNode comes back up, we find that the
DataNode never re-registers with the Standby NameNode. Thereafter failover completely fails.
> The desired behavior is that the DataNode's sendHeartbeat should timeout in 14 seconds,
and keep retrying till the Standby NameNode comes back up. When it does, the DataNode should
reconnect, re-register, and offer service.
> Specifically, in the class DatanodeProtocolClientSideTranslatorPB.java, the method createNamenode
should use RPC.getProtocolProxy and not RPC.getProxy to create the DatanodeProtocolPB object.
> Stack trace of thread stuck in the DataNode after the Standby NN has rebooted:
> Thread 25 (DataNode: [file:///opt/hadoop/data]  heartbeating to vmhost6-vm1/
>   State: WAITING
>   Blocked count: 23843
>   Waited count: 45676
>   Waiting on org.apache.hadoop.ipc.Client$Call@305ab6c5
>   Stack:
>     java.lang.Object.wait(Native Method)
>     java.lang.Object.wait(Object.java:485)
>     org.apache.hadoop.ipc.Client.call(Client.java:1220)
>     org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:202)
>     sun.proxy.$Proxy10.sendHeartbeat(Unknown Source)
>     sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>     sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     java.lang.reflect.Method.invoke(Method.java:597)
>     org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:164)
>     org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:83)
>     sun.proxy.$Proxy10.sendHeartbeat(Unknown Source)
>     org.apache.hadoop.hdfs.protocolPB.DatanodeProtocolClientSideTranslatorPB.sendHeartbeat(DatanodeProtocolClientSideTranslatorPB.java:167)
>     org.apache.hadoop.hdfs.server.datanode.BPServiceActor.sendHeartBeat(BPServiceActor.java:445)
>     org.apache.hadoop.hdfs.server.datanode.BPServiceActor.offerService(BPServiceActor.java:525)
>     org.apache.hadoop.hdfs.server.datanode.BPServiceActor.run(BPServiceActor.java:676)
>     java.lang.Thread.run(Thread.java:662)
> DataNode RPC to Standby NameNode never times out. 

This message was sent by Atlassian JIRA

View raw message