問題タブ [grpc]

私は SBT が初めてで、gradle protobuf/grpc 構成を SBT に変換しようとしています。

scala コミュニティが私より前にこれを行っていたのだろうか?

このプラグインhttps://github.com/sbt/sbt-protobufを試しましたが、grpc コンパイルを有効にするための構成は提供されません...

どんな助けでも感謝します。

関数を提供し、ストリームを返す GRPC サーバーがあります。ストリームをに保存したいmap[string]grpc.Stream- これは今のところうまくいきます。

私の問題は、ストリームを返す関数がロジックを終了した後にストリームが閉じられることです。

これは、私がこれまでに持っているものです：

私はすでに関数がリターンのfor {}前に何も返さないようにしようとしましたが（上記のコードでコメントされているように）、それは役に立たず、これが解決策になるとは思いません。

後で実行時にデータをクライアントに送信できるように、ストリームを開いたままにする方法はありますか?

I'm using gRPC to paginate a call and am trying to figure out the options for doing it/approximation for it. Is this a sensible question to ask? What are some resources I can use to do this?

PubSub をジョブ キューとして実験し、Google Cloud のインスタンスから実験を実行しています。

現在直面している問題は、PubSub での接続とジョブの作成に約 300 ミリ秒から 700 ミリ秒かかることです。私たちは PHP を実行しているため、受信リクエストごとに、残念ながら、PubSub への新しい接続を確立する必要があります (少なくともフロントエンド向けのコードでは)。これは PubSub サービスの予想される速度ですか、それとも何か間違っているのでしょうか?

もう 1 つの質問は、PubSub の gRPC に関するものです。これは有望に見えますが、PHP 環境でこれを試し始めるためのドキュメントやサンプル コードが見つからないようです。私が見つけた唯一の例は、AppEngine の外では利用できないクラスを使用する AppEngine で機能しているようです。

どちらの場合も、何か不足していることを願っています。PubSub を使用したいと思っています。

更新:クライアントにキャッシュを設定することで、問題を部分的に解決しました。しかし、それはまだ200ms-500msです

grpc呼び出しが機能しない理由を突き止めようとしていますが、デバッグを有効にする方法がわからないため、grpc 接続を介して送受信されているデータを確認できます。

grpc 呼び出しのデバッグを有効にするにはどうすればよいですか?

API 開発に grpc を使用しています。

これまでのところ、API を作成してアクセスすることができました。

「INFO: Server started. Listening on port 42420」メッセージが表示されてから約 5 秒後に、突然、この例外スタック トレースが連続して表示されるようになりました。

このプロジェクトをデプロイし、GCE インスタンスでサーバーを立ち上げました。誰かが以前に直面したことがある場合は、この問題の理由と解決策を教えてください。

スタックトレース：

gradle を使用する Java GRPC プロジェクトに OpenSSL を使用しています。

このリンクに記載されているように、セキュリティ設定を行う必要があると記載されているドキュメントを読みました。

build.gradle ファイルに osdetector プラグインを含めました。

しかし、プロジェクトをビルドすると、gradle は osdetector プラグインを解決できず、エラーがスローされます

私のgradleファイルは次のとおりです。

ただし、コンパイルの依存関係だけは解決されています。

ここで基本的な何かが欠けていると思います。解決策を教えてください。

更新しました

grpc と java を使用する私のプロジェクトでは、OpenSSL を使用してクライアントとサーバー間の安全な接続を確立しています。

grpc サーバーを正常に起動できました。

ここのドキュメントでは、安全なチャネルのクライアント コードはこれであると述べています。

次のようにクライアントでコードを使用していますが、以下の例外がスローされています。

例外：

次のコードでも試しました：

これも上記と同じ例外を与えています。ここで null ファイル参照を指定しました。

GoDaddy 証明書に使用するアプローチを教えてください。

それが最初のアプローチである場合、何が欠けていますか。

2 番目のアプローチの場合、「roots.pem」に使用するファイルはどれですか。

更新しました。

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 クエリの結果がすべてメモリにあるときではなく、到着したらすぐに処理したいのです。また、通話がハングしたときに、通話の待ち時間にタイムアウトが追加されます。そう、