一、Thrift 采坑
-
Thrift 的Server/Client有个较为严重的bug(https://issues.apache.org/jira/browse/THRIFT-601 ),随机向thrift sever的监听端口发些数据,可能会导致Server OutOfMemory,细细看看代码,这个bug有点土。
-
Thrift Client线程不安全,多线程下使用可能导致Server和客户端程序崩溃。Client的每次调用远程方法其实是有多次Socket写操作,因此每个线程中使用的Client要保证独立,如果多个线程混用同一个Client(其实是用同一个Socket),可能会导致传输的字节顺序混乱,使得Server OutOfMemory(参考1)
-
Thrift定义数据结构时,尽量避免用map, 或者set。在cpp下, map被对应为std::map(rb tree)和std::set,thrift生成的类不会重载”<”,因此需要手动修改生成类,否则link没法通过。较为麻烦。
-
如果Client端基于效率考虑,要缓存Socket,需要重新实现其TTransport类,以支持 Socket缓存池。当然,这个实现其实跟thrift没多大关系,算是2次开发。但一般都要这么做的吧?
-
如果Client基于效率考虑,缓存了Socket,那么thrift Server端的模式选择就较为重要了。如果使用同步的TThreadPoolServer,那么无可避免的,客户端缓存1个Socket,Server端就会有一个线程一直处于Server状态,等待peek这个S