Google Cloud Bigtable に対して呼び出しを行う gRPC C++ クライアントに問題があります。これらの通話はときどきハングしますが、通話の締め切りが設定されている場合にのみ、通話が返されます。gRPC チーム ( https://github.com/grpc/grpc/issues/6278)に提出された問題があり、スタック トレースと gRPC トレース ログが提供されています。
最も頻繁にハングする呼び出しは、ReadRowsストリーム読み取り呼び出しです。通話がハングするのも数回見MutateRowたことがありますが、それはかなりまれです。
gRPC トレースは、サーバーから何らかの応答が返されていることを示していますが、その応答は gRPC クライアントが続行するには不十分なようです。
コードのデバッグにかなりの時間を費やしましたが、これまでクライアント側で明らかな問題は見つかりませんでした。メモリの破損も見られませんでした。これはシングル スレッド アプリケーションであり、一度に 1 つの呼び出しを行います。クライアント側の同時実行性は疑わしいものではありません。クライアントは Google コンピューティング エンジン ボックスで実行されるため、ネットワークも問題にならない可能性があります。gRPC クライアントは、github リポジトリのメイン ラインで最新の状態に保たれます。
任意の提案をいただければ幸いです。デバッグのアイデアがあれば、それも素晴らしいでしょう。valgrind、gdb を使用して、アプリケーションを再現可能な結果のサブセットに縮小しても、これまでのところ役に立ちませんでした。問題の原因を突き止めることができませんでした。問題はランダムで、時折発生します。
2016 年 5 月 17 日の追記
再試行が問題の解決に役立つ可能性があるという提案がありました。残念ながら、再試行はアプリケーション ロジックに引き継がなければならないため、うまく機能しません。簡単に更新を再試行できます。MutateRowこれらはストリーミング コールではなく、簡単に再試行できます。ただし、DB クエリ結果の反復がアプリケーションによって開始された後、失敗した場合、再試行は、アプリケーションがクエリを再発行し、結果の反復を再度開始する必要があることを意味します。これは問題です。アプリケーションが結果セット全体を一度に読み取ってから、アプリケーション レベルで反復処理をメモリ内で実行できるようにする変更をいつでも検討できます。その後、再試行を処理できます。しかし、これは、メモリ フットプリントやアプリケーションのレイテンシなど、あらゆる種類の理由で問題になります。DB クエリの結果がすべてメモリにあるときではなく、到着したらすぐに処理したいのです。また、通話がハングしたときに、通話の待ち時間にタイムアウトが追加されます。そう、