在项目中遇到Thrift RPC Erlang库在处理大量数据时出现错误，经过排查发现是由于在接收数据时没有正确处理buffer不足的情况。通过分析库的源代码，发现在`thrift_socket_transport`模块的`recv`函数中，当接收到的数据长度小于预期时，没有进行循环接收。为了解决这个问题，提出了两种修改方案：在`thrift_binary_protocol`中增加判断并继续读取，或者在`thrift_socket_transport`中实现循环接收。最终选择了后者，新增`loop_recv`函数，成功修复了问题，确保了大数据和小数据RPC请求的正常处理。
我们项目的各个server之间是使用thrift rpc库来互相rpc的，我们使用的版本是0.9.2, 我制定了统一的消息格式，控制和包装好整个rpc的使用方法，来方便我们服务端的开发人员来使用，一开始因为rpc的数据量很少，所以基本没啥问题， 最近项目有一个大的rpc数据，开发反映rpc库报错，报错如下（用测试的demo工程来再现):
是typeid_to_atom()的参数匹配‘:'出了错，这就奇怪了，减少rpc数据请求量，又正常，在确认使用方法没有问题后，想到的是rpc参数是不是有哪个默认参数有问题，开始想到buffer不够大，去看buffer大小的限制，发现是一个list，这样就没有限制，排除这个原因。 再怀疑是recv timeout太短，默认是60秒，也排除。其它每一个参数都认真检查发现都没问题，这就怪了，这算是一个比较出名的库，应该不会代码有这么明显示的bug没测出来吧，参数反复检查没问题后，只能硬着头皮去看库的代码，花了一天时间，梳理了代码，整条线基本是这样：thrift_client:receive_function_result --> read_result --> handle_reply --> thrift_protocol:read --> read_specific -> thrift_protocol_binary:read -->read_data --> thrift_buffer_tran
最低0.47元/天 解锁文章
1436
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
