作為目前最流行的rpc框架，thrift不僅提供了通訊協議，同時提供了網路框架，解脫了程式設計師的生產力。thrift也是阿帕奇hadoop系列的rpc實現工具。本文主要聚焦在實現的thrift系統中，遇到的各種問題。
但是thrift在隱藏一些底層細節的同時，也給應用層帶來了一些不確定性，這些不確定和誤解，導致一些異常事件的發生。總結如下：
1、thrift compile在生成檔案的時候，生成php檔案時，同一命名空間下，不同的thrift檔案生成types.php，會導致檔案覆蓋（cpp和python沒有此問題）
2、服務端在採用tbufferedtransport時，該物件實際會自己快取
read/write buffer，當catch到異常時，僅僅close對應的socket，buffer並不會清空。此時如果再次open socket傳送資料，會導致buffer資料混亂，transport出現異常。解決的方法是把指向該tbufferedtransport的shared_ptr.reset()。
3、服務端和客戶端採用的協議必須一樣。服務端用tbufferedtransport，客戶端不能用tframeworktransport，否則會異常。客戶端報can't write *** bytes的異常
4、有時候會設定服務端和客戶端的超時，這時候如果另外一方在接/發資料的時候，未能在timeout時間內完成資料傳輸，則會由於另外一方的強制斷開而報異常。異常的內容是：broken pipe
5、如果thrift服務經常catch到異常，且異常的內容每次都不同，如broken pipe, no more data to read等，很有可能是在客戶端，多個執行緒共用乙個socket，卻沒有加鎖導致的heisenbug
6、服務端hander中，使用者實現的服務介面，不能有block的**，如sleep()，lock.wait()，否則會導致工作執行緒被阻塞。這樣引起的後果是：1，客戶端請求執行緒被卡死在socket::read()；2，服務端fd洩露
7、thrfit的client不能在多個執行緒間不加同步的復用，因為client不是執行緒安全的。
產品開發問題總結
公司和軟體系統開發分成兩部分，一部分叫產品，另一部分叫開發 他們之間的矛盾是這樣的，開發總是認為產品，文件或者產品的定義不清楚而，產品認為開發總是找事，或者說肯定是一次性不說不清楚的，所以文件有問題是理所當然的。大家都沒有錯。所有人讓開發也參加產品的討論會。希望這樣可以解決問題，這樣能解決問題嗎？首...
VS C 開發問題總結
1 新建的mfc 對話方塊cstring和char 的轉換一直失敗 vs工程預設配置 在網上看了很多cstring轉char 的方法，但是轉換一直失敗，例如以下幾種方式 cstring m ipaddr 192.168.1.100 char ipaddr lpstr lpctstr m ipaddr...
H5開發問題總結
local 和session 都無法直接訪問物件，當你定義乙個 json 以後 通過setitem 和getiem 後發現無法正常使用，應為local session 都是支援字串的訪問，所以這是需要兩個步驟第一就是在存的時候吧json 轉化成字串，當取出的時候再把字串解析成json 例如 var ...