首页 文章 精选 留言 我的

2.X版本的一个通病问题

2022-06-22 536

【概述】

对于配置了HA模式的RM或者NN，客户端如果向standby的节点发送请求，会因为不可连接或standby拒绝提供服务导致请求失败，转而向Active的节点发送请求，这个转换是hadoop客户端内部自动完成的，无须上层业务感知（本质上是向其中一个节点发送请求，如果失败则继续向另外一个节点发送请求）。

上周排查了一个相关的问题，在集群正常的情况下，向两个节点发送请求都失败，并且是持续失败，从而陷入死循环。最后发现是hadoop内部RPC机制的问题，并且在2.X版本中，该问题都是存在的。本文就来聊聊这个问题。

【问题现象】

某天，上层业务部分的兄弟反馈了一个问题，其现象是yarn client请求某个应用(application)的状态失败。

了解到问题现象后，首先查看了两个RM的日志，并未发现有什么错误的日志信息；接着通过命令行与yarn client分别尝试获取了"有问题"application的状态，发现也都是可以正确获取到的。

再次与该兄弟沟通后发现只有该application有问题，其他application都能正确获取到。同时给出了该application获取时的报错信息

22/06/20 20:48:06 DEBUG ipc.Client: IPC Client (1291113768) connection to resourcemanager-0/172.16.55.7:8032 from 28573: closed
22/06/20 20:48:06 TRACE ipc.ProtobufRpcEngine: 1: Exception <- resourcemanager-0/172.16.55.7:8032: getApplicationReport {java.net.ConnectException: Call From pvs285731713/10.33.72.132 to resourcemanager-0:8032 failed on connection exception: java.net.ConnectException: Connection refused: no further information; For more details see: http://wiki.apache.org/hadoop/ConnectionRefused}
22/06/20 20:48:06 TRACE retry.RetryInvocationHandler: Call#-2: ApplicationBaseProtocol.getApplicationReport([application_id { id: 1 cluster_timestamp: 1655720645233 }])
java.net.ConnectException: Call From pvs285731713/10.33.72.132 to resourcemanager-0:8032 failed on connection exception: java.net.ConnectException: Connection refused: no further information; For more details see: http://wiki.apache.org/hadoop/ConnectionRefused
  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
  at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
  at org.apache.hadoop.net.NetUtils.wrapWithMessage(NetUtils.java:827)
  at org.apache.hadoop.net.NetUtils.wrapException(NetUtils.java:757)
  at org.apache.hadoop.ipc.Client.getRpcResponse(Client.java:1553)
  at org.apache.hadoop.ipc.Client.call(Client.java:1495)
  at org.apache.hadoop.ipc.Client.call(Client.java:1394)
  at org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
  at org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:118)
  at com.sun.proxy.$Proxy7.getApplicationReport(Unknown Source)
  at org.apache.hadoop.yarn.api.impl.pb.client.ApplicationClientProtocolPBClientImpl.getApplicationReport(ApplicationClientProtocolPBClientImpl.java:236)
  at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:498)
  at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:422)
  at org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invokeMethod(RetryInvocationHandler.java:165)
  at org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invoke(RetryInvocationHandler.java:157)
  at org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invokeOnce(RetryInvocationHandler.java:95)
  at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:359)
  at com.sun.proxy.$Proxy8.getApplicationReport(Unknown Source)
  at org.apache.hadoop.yarn.client.api.impl.YarnClientImpl.getApplicationReport(YarnClientImpl.java:509)
  at Test.main(Test.java:27)
Caused by: java.net.ConnectException: Connection refused: no further information
  at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
  at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
  at org.apache.hadoop.net.SocketIOWithTimeout.connect(SocketIOWithTimeout.java:206)
  at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:532)
  at org.apache.hadoop.ipc.Client$Connection.setupConnection(Client.java:701)
  at org.apache.hadoop.ipc.Client$Connection.setupIOstreams(Client.java:814)
  at org.apache.hadoop.ipc.Client$Connection.access$3700(Client.java:423)
  at org.apache.hadoop.ipc.Client.getConnection(Client.java:1610)
  at org.apache.hadoop.ipc.Client.call(Client.java:1441)
  ... 16 more
22/06/20 20:48:06 INFO retry.RetryInvocationHandler: java.net.ConnectException: Call From pvs285731713/10.33.72.132 to resourcemanager-0:8032 failed on connection exception: java.net.ConnectException: Connection refused: no further information; For more details see: http://wiki.apache.org/hadoop/ConnectionRefused, while invoking ApplicationClientProtocolPBClientImpl.getApplicationReport over rm1 after 4 failover attempts. Trying to failover after sleeping for 1017ms.
22/06/20 20:48:06 TRACE retry.RetryInvocationHandler: #-2 processRetryInfo: retryInfo=RetryInfo{retryTime=5131870305, delay=1017, action=RetryAction(action=FAILOVER_AND_RETRY, delayMillis=1017, reason=null), expectedFailoverCount=12, failException=null}, waitTime=1016
22/06/20 20:48:08 INFO client.ConfiguredRMFailoverProxyProvider: Failing over to rm2
22/06/20 20:48:08 TRACE ipc.ProtobufRpcEngine: 1: Call -> resourcemanager-1:8032: getApplicationReport {application_id { id: 1 cluster_timestamp: 1655720645233 }}
22/06/20 20:48:08 TRACE ipc.ProtobufRpcEngine: 1: Exception <- resourcemanager-1:8032: getApplicationReport {java.net.UnknownHostException: Invalid host name: local host is: (unknown); destination host is: "resourcemanager-1":8032; java.net.UnknownHostException; For more details see: http://wiki.apache.org/hadoop/UnknownHost}
22/06/20 20:48:08 TRACE retry.RetryInvocationHandler: Call#-2: ApplicationBaseProtocol.getApplicationReport([application_id { id: 1 cluster_timestamp: 1655720645233 }])
java.net.UnknownHostException: Invalid host name: local host is: (unknown); destination host is: "resourcemanager-1":8032; java.net.UnknownHostException; For more details see: http://wiki.apache.org/hadoop/UnknownHost
  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
  at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
  at org.apache.hadoop.net.NetUtils.wrapWithMessage(NetUtils.java:827)
  at org.apache.hadoop.net.NetUtils.wrapException(NetUtils.java:770)
  at org.apache.hadoop.ipc.Client$Connection.<init>(Client.java:461)
  at org.apache.hadoop.ipc.Client.getConnection(Client.java:1590)
  at org.apache.hadoop.ipc.Client.call(Client.java:1441)
  at org.apache.hadoop.ipc.Client.call(Client.java:1394)
  at org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
  at org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:118)
  at com.sun.proxy.$Proxy7.getApplicationReport(Unknown Source)
  at org.apache.hadoop.yarn.api.impl.pb.client.ApplicationClientProtocolPBClientImpl.getApplicationReport(ApplicationClientProtocolPBClientImpl.java:236)
  at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:498)
  at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:422)
  at org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invokeMethod(RetryInvocationHandler.java:165)
  at org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invoke(RetryInvocationHandler.java:157)
  at org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invokeOnce(RetryInvocationHandler.java:95)
  at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:359)
  at com.sun.proxy.$Proxy8.getApplicationReport(Unknown Source)
  at org.apache.hadoop.yarn.client.api.impl.YarnClientImpl.getApplicationReport(YarnClientImpl.java:509)
  at Test.main(Test.java:27)
Caused by: java.net.UnknownHostException
  ... 19 more
22/06/20 20:48:08 INFO retry.RetryInvocationHandler: java.net.UnknownHostException: Invalid host name: local host is: (unknown); destination host is: "resourcemanager-1":8032; java.net.UnknownHostException; For more details see: http://wiki.apache.org/hadoop/UnknownHost, while invoking ApplicationClientProtocolPBClientImpl.getApplicationReport over rm2 after 5 failover attempts. Trying to failover after sleeping for 2978ms.

【问题分析】

结合上面的情况整体进行分析：RM没有报错，并且通过命令行可以正确获取到application的状态，因此基本排除服务端存在问题的可能性；而在业务中，只有该application不能查到，其他application都正常；并且在业务端的使用方式为：每个application使用一个独立的yarn client对象进行查询。到这里，基本可以确定是在客户端一侧出了问题。

再从上面的报错日志可以看出，因为RM1是standby，并未监听8032端口，因此客户端向RM1建立连接失败这个是正常的逻辑，接着继续向RM2建立连接发送请求，但与RM2连接时，抛出了UnknownHost的异常，重新又转向RM1请求，如此反复循环，导致出现了该问题。因此UnknownHost异常应该是导致请求失败的最大疑点。

我们还是通过走读源码，从掌握交互逻辑流程来进一步分析该问题。

首先，客户端创建连接对象时，会判断服务端的地址是否已经解析，如果未解析则直接抛出异常（这也就是前面问题抛异常的地方）

public Connection(ConnectionId remoteId, int serviceClass) throws IOException {
    this.remoteId = remoteId;
    this.server = remoteId.getAddress();
    if (server.isUnresolved()) {
        throw NetUtils.wrapException(
            server.getHostName(),
            server.getPort(),
            null,
            0,
            new UnknownHostException());
    }
    ...
}

其次，对于服务端采用HA模式部署时，客户端的RPC代理层会有一个重试逻辑：对于单个rpc请求过程中的异常，通过回调切换到另外一个RM，并获取对应的proxy对象，继续进行请求访问。

在获取proxy对象时，内部实际上是对不同RM分别创建proxy对象，并缓存在map中，下次使用时直接从map中获取。

// ConfiguredRMFailoverProxyProvider.java
public synchronized ProxyInfo<T> getProxy() {
    String rmId = rmServiceIds[currentProxyIndex];
    T current = proxies.get(rmId);
    if (current == null) {
        current = getProxyInternal();
        proxies.put(rmId, current);
    }
    return new ProxyInfo<T>(current, rmId);
}

在首次创建proxy对象时，对服务端的地址进行解析，如果无法解析出地址，则创建一个未解析的套接字，保存在proxy对象中（注：建立连接时使用的就是该套接字）

// ConfiguredRMFailoverProxyProvider.java
// 获取proxy对象
protected T getProxyInternal() {
    try {
        // 解析RM的地址
        final InetSocketAddress rmAddress = rmProxy.getRMAddress(conf, protocol);
        return rmProxy.getProxy(conf, protocol, rmAddress);
    } catch (IOException ioe) {
        LOG.error(
            "Unable to create proxy to the ResourceManager " +
            rmServiceIds[currentProxyIndex], ioe);
        return null;
    }
}

// ClientRMProxy.java
public InetSocketAddress getRMAddress(YarnConfiguration conf, Class<?> protocol) 
    throws IOException {
    if (protocol == ApplicationClientProtocol.class) {
        return conf.getSocketAddr(
            YarnConfiguration.RM_ADDRESS,
            YarnConfiguration.DEFAULT_RM_ADDRESS,
            YarnConfiguration.DEFAULT_RM_PORT);
    } 
    ...
}

// Configuration.java
public InetSocketAddress getSocketAddr(
    String name, String defaultAddress, int defaultPort) {
    final String address = getTrimmed(name, defaultAddress);
    return NetUtils.createSocketAddr(address, defaultPort, name);
}

// NetUtils.java
public static InetSocketAddress createSocketAddr(String target, int defaultPort, String configName) {
    ...
    return createSocketAddrForHost(host, port);
}

public static InetSocketAddress createSocketAddrForHost(String host, int port) {
    String staticHost = getStaticResolution(host);
    String resolveHost = (staticHost != null) ? staticHost : host;

    InetSocketAddress addr;
    try {
        InetAddress iaddr = SecurityUtil.getByName(resolveHost);
        // if there is a static entry for the host, make the returned
        // address look like the original given host
        if (staticHost != null) {
            iaddr = InetAddress.getByAddress(host, iaddr.getAddress());
        }
        addr = new InetSocketAddress(iaddr, port);
    } catch (UnknownHostException e) {
        // 捕获异常并创建未解析的套接字
        addr = InetSocketAddress.createUnresolved(host, port);
    }
    return addr;
}

看到这里，可以分析出原因：即只有首次创建proxy对象时才会对服务端的地址进行解析保存，同时proxy对象会缓存在map中循环使用；而真正进行连接时会判断地址是否已经解析，如果未解析则直接抛出异常，如果未解析出的地址的RM恰好是Active的话，就会导致出现该问题。

另外，该问题仅仅对单个客户端（yarn client）有问题，不会影响其他客户端，这也就可以解释为什么业务侧只有某个application无法正确获取到，其他都正常，同时再次通过命令行或者客户端获取时又能正确获取到。

最后，如果业务侧对于异常的处理的方式是新建一个客户端，而不是继续复用该客户端对象发送请求，也不会出现该问题。

【问题解决】

问题的解决其实比较简单，在社区中也已经有人发现了该问题，并提交了patch，具体修改为：去除了创建连接时对服务端地址是否解析的判断，同时在真正建立连接时，对于未解析的地址抛出异常并捕获触发重新解析。

因此只需要引入该patch即可解决。

【总结】

小结一下，本文通过一个案例，讲述了hadoop中rpc内部缓存导致的一个问题，除此之外，hadoop的rpc中还有不少细节，我们也都踩过一些坑，后面我们再展开聊聊。

好了，这就是本文的全部内容，如果觉得本文对您有帮助，不要吝啬点赞在看转发，也欢迎加我微信交流～

 

本文分享自微信公众号 - hncscwc（gh_383bc7486c1a）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。

上一篇 下一篇
优秀的个人博客,低调大师

微信关注我们

原文链接：https://my.oschina.net/hncscwc/blog/5544343

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

钟珊珊：被爆锤后的工程师会起飞｜OneFlow U

钟珊珊，一流科技工程师（实习），本科毕业于中山大学信息管理与信息系统专业，现在是中山大学计算机学院的准研究生。 大学期间，她担任多个项目的主要负责人，并在数据驱动创新研究等高校大赛斩获了一众奖项，积累了技术实践经验。毕业后，在师兄师姐的推荐下，她来到 OneFlow 实习。 她平时喜欢弹吉他，自称弹得并不怎么样，但嘈嘈切切错杂弹让她感觉很自由、快乐、且放松。她似乎还有点随性，大四时，她把 GPA 排名刷到了专业第一，但这时已经不评奖学金了；她选择保研本校的中山大学计算机学院，是因为这样搬宿舍不会太累…… 以下是钟珊珊自述。 中山大学的院系设置比较有趣，计算机学院、软件学院、电子与信息学院、智能工程学院、人工智能学院等都有 AI 方向的专业。其中，人工智能学院在珠海校区，所以读研我更倾向于在广州的计算机学院，这样的话，搬宿舍不用太累。 大四时，我把 GPA 排名刷到了第一，但这时我们已经不评选奖学金了呜呜呜……在学习上，我觉得多做笔记非常重要。当然，课本上的也不是都要一点不落地记下来，而是对课程中自己感兴趣的点深入挖掘，多在课堂分享，多找老师讨论。 对我来说，学一项东西最快的...
2022-06-22
454
上一篇

应用实践 | Apache Doris 整合 Iceberg + Flink CDC 构建实时湖仓一体的联邦查询分析架构

应用实践 | Apache Doris 整合 Iceberg + Flink CDC 构建实时湖仓一体的联邦查询分析架构 导读：这是一篇非常完整全面的应用技术干货，手把手教你如何使用 Doris+Iceberg+Flink CDC 构建实时湖仓一体的联邦查询分析架构。按照本文中步骤一步步完成，完整体验搭建操作的完整过程。 作者｜Apache Doris PMC 成员 张家锋 1.概览 这篇教程将展示如何使用 Doris+Iceberg+Flink CDC 构建实时湖仓一体的联邦查询分析，Doris 1.1版本提供了Iceberg的支持，本文主要展示Doris和Iceberg怎么使用，同时本教程整个环境是都基于伪分布式环境搭建，大家按照步骤可以一步步完成。完整体验整个搭建操作的过程。 1.1 软件环境 本教程的演示环境如下： Centos7 Apahce doris 1.1 Hadoop 3.3.3 hive 3.1.3 Fink 1.14.4 flink-sql-connector-mysql-cdc-2.2.1 Apache Iceberg 0.13.2 JDK 1.8.0_311 ...
2022-06-23
533
下一篇

相关文章

发表评论

资源下载

更多资源
优质分享App

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

时间: 2025-12-03 大小: 4.36MB 下载: 23次
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2025-12-12 大小: 211.28KB 下载: 54次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2025-12-17 大小: 5MB 下载: 1次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-01-03 大小: 1.42GB 下载: 2次
手机查看

扫码在手机上查看文章

扫描二维码，手机阅读更方便

热门标签
Docker Nacos3 SpringBoot4 OpenAi SpringCloud Rocky Gemini3 Kubernetes Jdk25 DeepSeek Service Mesh Redis HarmonyOS6

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册