概述¶¶
近期某使用mule的项目在与N公司联调时发现对方的请求存在严重延迟. 请求是基于TCP协议的.
通过一步步分析, 最终定位到问题的根源并解决. 通过本文对整个过程进行下梳理和总结...."他换了6040端口,应用可以立马收到. 8110端口就有问题, 服务器上能收到,就是他应用收不到"
对以上的描述梳理后, 事实没有更新, 但我自己基本上断定问题和主机/网络无关, 而应该是应用的问题....拿不到数据2个原因:
mule 这个组件比较特殊, 没有对应的插件;
报文直接走的4层TCP协议, pinpoint无法抓到4层TCP.
所以最后还是安装Dynatrace了监控....(加入sensor, 抓取第三个参数int)
4. 加入后, 发现会调用4次, 前3次都很快, 第4次超时. 第四次int是416报文长度. 但是这个却执行了近500s....问题根因详细说明¶
开发老师的根因详细说明:
问题定位到了,mule的一个getway方法对渠道请求做TCP解析后再把消息转给mule-forN公司 8110端口,现在是接收到渠道416个字符,但是重新