news 2026/5/2 14:50:13

rocketmq org.apache.rocketmq.remoting.exception.RemotingTimeoutException: invokeSync call timeout

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
rocketmq org.apache.rocketmq.remoting.exception.RemotingTimeoutException: invokeSync call timeout

在RocketMQ客户端的DefaultMQPushConsumer的start方法被执行时,时不时会报出invokeSync call timeout异常,如下:

Caused by: java.lang.IllegalStateException: org.apache.rocketmq.remoting.exception.RemotingTimeoutException: invokeSync call timeout at org.apache.rocketmq.client.impl.factory.MQClientInstance.updateTopicRouteInfoFromNameServer(MQClientInstance.java:679) ~[rocketmq-client-4.7.1.jar:4.7.1] at org.apache.rocketmq.client.impl.factory.MQClientInstance.updateTopicRouteInfoFromNameServer(MQClientInstance.java:509) ~[rocketmq-client-4.7.1.jar:4.7.1] at org.apache.rocketmq.client.impl.consumer.DefaultMQPushConsumerImpl.updateTopicSubscribeInfoWhenSubscriptionChanged(DefaultMQPushConsumerImpl.java:872) ~[rocketmq-client-4.7.1.jar:4.7.1] at org.apache.rocketmq.client.impl.consumer.DefaultMQPushConsumerImpl.start(DefaultMQPushConsumerImpl.java:653) ~[rocketmq-client-4.7.1.jar:4.7.1] at org.apache.rocketmq.client.consumer.DefaultMQPushConsumer.start(DefaultMQPushConsumer.java:698) ~[rocketmq-client-4.7.1.jar:4.7.1] at cn.xdf.xcloud.rocketmq.support.DefaultRocketMQListenerContainer.start(DefaultRocketMQListenerContainer.java:276) ~[xcloud-rocketmq-core-1.2.0.RELEASE.jar:1.2.0.RELEASE] at cn.xdf.xcloud.rocketmq.autoconfigure.ListenerContainerConfiguration.registerContainer(ListenerContainerConfiguration.java:103) ~[xcloud-rocketmq-core-1.2.0.RELEASE.jar:1.2.0.RELEASE] ... 12 common frames omitted Caused by: org.apache.rocketmq.remoting.exception.RemotingTimeoutException: invokeSync call timeout at org.apache.rocketmq.remoting.netty.NettyRemotingClient.invokeSync(NettyRemotingClient.java:375) ~[rocketmq-remoting-4.7.1.jar:4.7.1] at org.apache.rocketmq.client.impl.MQClientAPIImpl.getTopicRouteInfoFromNameServer(MQClientAPIImpl.java:1363) ~[rocketmq-client-4.7.1.jar:4.7.1] at org.apache.rocketmq.client.impl.MQClientAPIImpl.getTopicRouteInfoFromNameServer(MQClientAPIImpl.java:1353) ~[rocketmq-client-4.7.1.jar:4.7.1] at org.apache.rocketmq.client.impl.factory.MQClientInstance.updateTopicRouteInfoFromNameServer(MQClientInstance.java:622) ~[rocketmq-client-4.7.1.jar:4.7.1] ... 18 common frames omitted

如果着急马上找到解决办法,可以直接跳到解决办法。不过,授人以鱼,不如授之以渔。还是建议把寻找解决办法的过程看完,第一:可以给你以后遇到类似问题提供解决思路;第二:虽然都报这个异常,但产生的原因可能不一样。

寻找解决办法之路

做为面向搜索引擎编程的一员,立马复制关键字invokeSync call timeout去搜索引擎,得到的解决办法总结起来有两点:

  1. RocketMQ客户端和服务端版本不一致,检查了一下客户端和服务端的版本,都是4.7.1。
  2. 降低RocketMQ客户端的版本,这个我时不能接受的。

搜索引擎无法解决,只能自己想办法了。首先找到报异常的地方:

public RemotingCommand invokeSync(String addr, final RemotingCommand request, long timeoutMillis) throws InterruptedException, RemotingConnectException, RemotingSendRequestException, RemotingTimeoutException { long beginStartTime = System.currentTimeMillis(); final Channel channel = this.getAndCreateChannel(addr); if (channel != null && channel.isActive()) { try { doBeforeRpcHooks(addr, request); long costTime = System.currentTimeMillis() - beginStartTime; if (timeoutMillis < costTime) { throw new RemotingTimeoutException("invokeSync call timeout"); } RemotingCommand response = this.invokeSyncImpl(channel, request, timeoutMillis - costTime); doAfterRpcHooks(RemotingHelper.parseChannelRemoteAddr(channel), request, response); return response; } //省略部分无关代码 } else { this.closeChannel(addr, channel); throw new RemotingConnectException(addr); } }

原来是因为代码执行的时间过长,才报出了invokeSync call timeout异常。首先想到的是延长超时时间,继续分析源码,向上寻找调用方,发现在MQClientInstanceupdateTopicRouteInfoFromNameServer方法中有:

topicRouteData = this.mQClientAPIImpl.getTopicRouteInfoFromNameServer(topic, 1000 * 3);

居然是写死了3秒,没有办法修改,我竟无语凝噎。

再向下一步一步地分析源码,到底是哪里慢?

org.apache.rocketmq.remoting.netty.NettyRemotingClient.getAndCreateChannel org.apache.rocketmq.remoting.netty.NettyRemotingClient.getAndCreateNameserverChannel org.apache.rocketmq.remoting.netty.NettyRemotingClient.createChannel io.netty.bootstrap.Bootstrap.connect(java.net.SocketAddress) io.netty.bootstrap.Bootstrap.doResolveAndConnect io.netty.bootstrap.AbstractBootstrap.initAndRegister io.netty.bootstrap.ChannelFactory.newChannel io.netty.channel.socket.nio.NioSocketChannel.NioSocketChannel() io.netty.channel.nio.AbstractNioChannel.AbstractNioChannel io.netty.channel.AbstractChannel.AbstractChannel(io.netty.channel.Channel) io.netty.channel.AbstractChannel.newId io.netty.channel.DefaultChannelId.newInstance

最终找到了:

public static DefaultChannelId newInstance() { return new DefaultChannelId(); }

在创建DefaultChannelId的实例时,执行了这个类的静态代码块,就是这段静态代码块比较耗时。

那么,解决办法就有了,提前加载DefaultChannelId类,使其静态代码块先执行完成。

解决办法

在调用DefaultMQPushConsumer的start方法之前,插入如下代码:

DefaultChannelId.newInstance();
版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/5/2 14:46:25

Sentry-MCP:让AI助手拥有实时项目诊断能力的全栈工程师

1. 项目概述与核心价值 最近在折腾AI驱动的代码助手时&#xff0c;发现一个痛点&#xff1a;当AI试图理解一个复杂的项目时&#xff0c;它往往只能看到代码本身&#xff0c;却对项目运行时的真实状态、错误日志、性能瓶颈这些“活”的信息一无所知。这就好比一个医生只看病历&…

作者头像 李华
网站建设 2026/5/2 14:41:28

AI代理平台架构融合:从Claude Code与Hermes Agent到OpenClaw的工程实践

1. 项目概述&#xff1a;从“三位一体”到下一代AI代理平台的构建 如果你和我一样&#xff0c;长期在AI代理开发的一线摸爬滚打&#xff0c;就会深刻体会到一个痛点&#xff1a;优秀的开源项目往往各有侧重&#xff0c;但鲜有能将“企业级架构”、“丰富工具生态”和“极致开发…

作者头像 李华
网站建设 2026/5/2 14:41:24

从90nm到3nm:聊聊工艺演进中,那些被我们忽略的STA基础概念变迁

从90nm到3nm&#xff1a;工艺演进中STA基础概念的范式转移 当台积电在2003年推出90nm工艺时&#xff0c;很少有人能预见20年后芯片制造会进入3nm时代。这场半导体工艺的微型化革命不仅改变了晶体管的结构&#xff0c;更彻底重构了静态时序分析(STA)的基础理论框架。对于经历过…

作者头像 李华
网站建设 2026/5/2 14:40:45

Go语言轻量级爬虫框架goclaw:模块化设计与高并发实践

1. 项目概述&#xff1a;一个轻量级的Go语言Web爬虫框架 最近在做一个需要从多个网站定时抓取结构化数据的小项目&#xff0c;用Python的Scrapy吧&#xff0c;感觉太重了&#xff0c;部署起来也麻烦&#xff1b;用原生的 net/http 库自己写&#xff0c;又得重复造轮子&#x…

作者头像 李华