Ich habe ein Problem mit gRPC C++ - Client, der Anrufe gegen Google Cloud Bigtable. Diese Anrufe hängen gelegentlich und nur wenn der Anruftermin eingestellt ist, kehrt der Anruf zurück. Es gibt ein Problem mit gRPC-Team: https://github.com/grpc/grpc/issues/6278 mit Stack-Trace und einem Stück gRPC Tracing-Protokoll zur Verfügung gestellt.gRPC C++ Client-Aufrufe gegen Bigtable hängt gelegentlich
Der Anruf, der am häufigsten hängt, ist ReadRows Stream lesen Anruf. Ich habe gesehen MutateRow Anruf ein paar Mal hängen, aber das ist eher selten.
gRPC-Tracing zeigt, dass einige Antworten vom Server kommen, diese Antwort scheint jedoch für den gRPC-Client nicht ausreichend zu sein.
Ich verbrachte eine ganze Weile damit, den Code zu debuggen, keine offensichtlichen Probleme, die bisher auf der Clientseite gefunden wurden, keine Speicherbeschädigungen. Dies ist eine single-threaded-Anwendung, die einen Aufruf nach dem anderen durchführt. Die clientseitige Nebenläufigkeit ist kein Verdächtiger. Der Client wird in der Google Compute Engine-Box ausgeführt, daher ist das Netzwerk wahrscheinlich auch kein Problem. Der gRPC-Client wird mit der Github-Repository-Hauptleitung auf dem neuesten Stand gehalten.
Irgendwelche Vorschläge würden geschätzt. Wenn jemand Ideen debuggen würde, wäre das auch großartig. Valgrind, gdb, die Anwendung auf eine Teilmenge mit reproduzierbaren Ergebnissen zu reduzieren, half bisher nicht, ich war nicht in der Lage herauszufinden, was das Problem ist. Das Problem ist zufällig und taucht gelegentlich auf.
Zusätzliche Anmerkung am 17. Mai 2016 Es gab einen Vorschlag, dass erneute Versuche helfen können, mit dem Problem umzugehen. Leider funktionieren die Wiederholungen nicht sehr gut für uns, weil wir das in die Anwendungslogik übertragen müssten. Wir können problemlos Updates erneut versuchen, die MutateRow Anrufe sind, und wir tun das, diese sind keine Streaming-Anrufe und einfach wieder zu versuchen. Sobald jedoch die Iteration der DB-Abfrageergebnisse von der Anwendung gestartet wurde, bedeutet das erneute Versuchen, dass die Anwendung die Abfrage erneut ausgeben und die Iteration der Ergebnisse erneut starten muss. Was ist problematisch? Es ist immer möglich, eine Änderung in Erwägung zu ziehen, die dazu führt, dass unsere Anwendungen die gesamte Ergebnismenge auf einmal lesen und dann auf der Anwendungsebene Iterationen im Speicher ausführen können. Dann können erneute Versuche behandelt werden. Aber das ist aus allen möglichen Gründen problematisch, wie Speicherbedarf und Anwendungslatenzen. Wir möchten DB-Abfrageergebnisse verarbeiten, sobald sie ankommen, nicht wenn alle im Speicher sind. Es wird auch eine Zeitüberschreitung zu der Anruflatenz hinzugefügt, wenn der Anruf aufhört. Daher sind Wiederholungsversuche der Abfrageergebnis-Iterationen in einem solchen Ausmaß wirklich kostspielig, dass sie nicht praktikabel sind.
Lange laufende Lesevorgänge sind definitiv problematisch. Der Java Bigtable-Client verfolgt, was er gesehen hat, und erstellt dann eine neue Anforderung, die nach den zuletzt gesehenen Zeilen beginnt. Dies ist ein nuanciertes Problem. Fühlen Sie sich frei, mich bei sduskis at goog le dot com zu erreichen. –
Dies sind keine lang laufenden Abfragen. Die Fehler, die ich sehe, sind normalerweise die allerersten Leseanrufe des Streams. Und das sind keine langen Sitzungen. Ich sehe diese Fehler innerhalb von ein oder zwei Minuten einer Test-App. – ay60