dubbo异常Data length too large

记录下dubbo服务报错Data length too large的异常

生产dubbo调用,dubbo服务方报错

dubbo异常Data length too large

根据堆栈查看了下com.alibaba.dubbo.remoting.transport.AbstractCodec.checkPayload(Channel, long),发现是数据太大,超过了dubbo的报文体最大长度限制8M,dubbo默认报文体限制是int DEFAULT_PAYLOAD = 8 * 1024 * 1024,即8m。从上图日志里面看,要发送的报文体是13116835,大概12.5m。也是奇怪,一个简单的查询调用,运行了快一年第一次出现这个问题。是哪里出现问题了呢?

经过排查,发现要返回的一个consoleLog太大导致的,这个字段保存的是shell执行日志,从数据库查看,该字段内容确实很大,里面chown: changing ownership of '/home/user/data1/export/20201129/13/XXXX.xlsx': Operation not permitted 大概有5w多行,这样就基本12.5m了,为什么脚本执行会报错大量的这个异常呢? 经过跟业务组咨询,他们这个应用生成报表在/home/user/data1目录,这样在执行chown -R user:user /home/user的时候,由于该目录下的Excel文件太多(5w多个),这样每条就报错这个错误。但是问题来了,这些excel都是由应用生成,而应用又是由user用户启动,按理chown命令不应该出现这样的问题(经过到服务器查看这些Excel确实是属于user用户),问题出现在哪呢?

想到要生成这么多报表excel文件,那么肯定需要比较大的磁盘空间,平时生产给的虚机应用通常是200g,这么多文件按理磁盘空间应该是不足的,是不是对磁盘做了什么特殊处理,经过咨询系统的开发,说他们文件系统/home/user找过运维扩容过,是挂载磁盘(nfs),那么问题很明显出现在nfs上。继而咨询了运维得到答案,nfs 默认运行是 root_squash。client 挂载无法执行,权限操作。需要改为需要改成 no_root_squash 才可以,知道了问题就好解决了,我们的脚本不应该对/home/user再进行chown -R user:user /home。还有就是不要再查询consoleLog。

如果要增大dubbo最大报文限制,可以通过dubbo.protocol.payload=20*1024*1024 设置为20m,但是通常不建议设置。

上一篇:【PTA-乙级-详解】 1024科学计数法


下一篇:Java之向上转型的内存图