我遇到了gRPC C++客戶端針對谷歌雲Bigtable進行調用的問題。這些電話偶爾會掛起，只有在呼叫返回時設置了呼叫截止日期。 gRPC團隊存在一個問題：https://github.com/grpc/grpc/issues/6278帶有堆棧跟蹤和提供的一條gRPC跟蹤日誌。gRPC針對Bigtable的C++客戶端調用偶爾掛起
最常掛起的呼叫是ReadRows流讀取呼叫。我看到MutateRow呼叫掛了幾次，但這是相當罕見的。
gRPC跟蹤顯示有一些響應從服務器返回，但該響應似乎不足以讓gRPC客戶端繼續進行。
我確實花費了相當多的時間調試代碼，目前在客戶端沒有發現任何明顯的問題，沒有發現內存損壞。這是一個單線程應用程序，一次只進行一次調用，客戶端併發性不是可疑的。客戶端運行在谷歌計算引擎框中，因此網絡可能也不是問題。 gRPC客戶端與github存儲庫主線保持同步。
任何建議，將不勝感激。如果有人有調試的想法，那也會很棒。使用valgrind，gdb，將應用程序減少到具有可重現結果的子集並沒有幫助，但我一直無法找出問題所在。問題是隨機的，偶爾會出現。
2016年5月17日的補充說明 有人建議重新嘗試可能有助於解決問題。 不幸的是，重試對我們來說效果並不好，因爲我們必須將其轉換到應用程序邏輯中。我們可以輕鬆地重新嘗試更新，即MutateRow調用，我們這樣做，這些不是流式調用，並且很容易重新嘗試。但是，一旦數據庫查詢結果的迭代已經由應用程序開始，如果失敗，重試意味着應用程序需要重新發出查詢並重新開始迭代結果。這是有問題的。始終可以考慮一個變化，它會讓我們的應用程序一次讀取整個結果集，然後在應用程序級迭代可以在內存中完成。然後重新嘗試可以處理。但是，由於各種原因（如內存佔用和應用程序延遲），這是有問題的。我們希望在數據庫查詢結果到達時立即處理，而不是在所有數據都在內存中時處理。呼叫掛起時，呼叫延遲時間也會增加。因此，對查詢結果迭代的重新嘗試實際上代價很高，以至於不切實際。
長時間運行讀取肯定存在問題。 Java Bigtable客戶端跟蹤它看到的內容，然後在最後一次看到的行之後開始創建一個新的請求。這是一個細微的問題。請隨時聯繫goog le dot com的sduskis。 –
這些不是長時間運行的查詢。我看到的失敗通常是流的第一次讀取調用。這些都不是長時間運行的會話。我在運行測試應用程序的一兩分鐘內看到這些故障。 – ay60