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的話，可以看看這個東西。