原文：http://blog.rushcj.com/2010/08/21/try-thrift/

Thrift是一个非常棒的工具，是Facebook的开源项目，目前的开发非常的活跃，由Apache管理，所以用的是Apache Software License，这非常重要，因为可以放心的对其修改并用到自己的项目中。

谈到修改Thrift,这非常重要。因为我觉得如果要严肃的使用Thrift，不可避免的要深入了解它，并几乎都要修改Thrift的代码。一个通信框架，它不可能帮你做到所有的事情，也不可能在不了解的情况下就贸然的使用。

1.Thrift 的Java Server/Client有个较为严重的bug(https://issues.apache.org/jira/browse/THRIFT-601 )，随机向thrift  sever的监听端口发些数据，可能会导致Server OutOfMemory，细细看看代码，这个bug有点土。

2.Thrift Client线程不安全，多线程下使用可能导致Server和客户端程序崩溃。Client的每次调用远程方法其实是有多次Socket写操作，因此每个线程中使用的Client要保证独立，如果多个线程混用同一个Client(其实是用同一个Socket)，可能会导致传输的字节顺序混乱，使得Server OutOfMemory(参考1）

3.Thrift定义数据结构时，尽量避免用map, 或者set。在cpp下, map被对应为std::map(rb tree)和std::set，thrift生成的类不会重载”<”，因此需要手动修改生成类，否则link没法通过。较为麻烦。

4.如果Client端基于效率考虑，要缓存Socket，需要重新实现其TTransport类，以支持 Socket缓存池。当然，这个实现其实跟thrift没多大关系，算是2次开发。但一般都要这么做的吧？

5.如果Client基于效率考虑，缓存了Socket，那么thrift Server端的模式选择就较为重要了。如果使用同步的TThreadPoolServer，那么无可避免的，客户端缓存1个Socket，Server端就会有一个线程一直处于Server状态，等待peek这个Socket上的数据。这个线程就不能用于其它请求了。所以，及时清理Client端的Socket及控制Socket池的大小是非常必要的。

6.听同事说CPP Thrift Server的Epoll NonBlocking模式有效率问题。其实，并发要求不高的Server用LT模式的EPoll其实很方便的，当然，这个要自己给Thrfit Server做patch了，不过也不麻烦。开发起来也是很方便的。我想给我们的Server加个EPOLLONESHOT的同步EPoll实现。

7.CPP下的 TThreadPoolServer和TThreadServer由一个有趣的问题，如果有客户端维护长连接，那么对这个Server实例做析构的时候会堵塞（前面说过了，在peek中…）。

8.用valgrind看，thrift cpp似乎有一些内存问题。没细看。

9.无论是Java，还是CPP，Server端都无法通过合法的方式获取Client的ip, port。可以通过编写ThriftServerEventHandler可以处理这件事情。如果想要获取Client ip, port的话，可以看看这个东西。