首先声明：我这个问题不是网络问题，出现这个报错优先看网络是否ok。

最近公司在做架构升级，对于RocketMq也做了升级，升级后启动项目直接报错send request to <xxxx:9876> failed。很奇怪研究了一波，此处记录下。

1. pom文件升级到新版之后，启动项目报错，debug定位到是如下方法报错

//DefaultMQPushConsumerImpl下：这段逻辑中直接报错了failed的异常
this.updateTopicSubscribeInfoWhenSubscriptionChanged();

//NettyRemotingClient下：继续往下走到发现是这里
RemotingCommand response = this.remotingClient.invokeSync(null, request, timeoutMillis);

//NettyRemotingAbstract下：看了下这个方法内部就是简单的netty的交互，此处的responseCommand返回的一直是null
RemotingCommand responseCommand = responseFuture.waitResponse(timeoutMillis);

2. 继续走发现是调用服务端的问题，问题出现在netty通信上。此时很好奇为什么服务端没有相应。

3. 通过wireshark抓包看下，按照nameserver中的ip去过滤一下

发现服务端的返回值是有的，说明问题出现在代码框架上了。

4.打开rocketmq的包结构看了一下发现一个很明显的问题

历史代码原因引入了低版本的guava，凑他猴子。干掉就ok了。

总结经验：碰到这种首先看网络是否ok，因为我是老项目能用，新项目不能用都在一个环境。排除了网络因素。然后对于网络io的这种直接抓包把它底裤看穿。最后能定位到就是代码问题了，那9成9就是某个包冲突了。找到它，干掉它就可以了。