У меня проблема с клиентом gRPC C++, который вызывает вызовы с облаком Google Bigtable. Эти вызовы иногда зависают, и только если установлен крайний срок вызова, возвращается вызов. Существует проблема с командой gRPC: https://github.com/grpc/grpc/issues/6278 с трассировкой стека и предоставлена часть журнала трассировки gRPC.gRPC C++ клиентские вызовы против Bigtable иногда зависает
Звонок, который чаще всего зависает, - это ReadRows Поток для чтения. Я видел MutateRow звонок висит несколько раз, но это довольно редко.
gRPC tracing показывает, что есть какой-то ответ, возвращающийся с сервера, однако этот ответ, кажется, недостаточен для того, чтобы клиент gRPC продолжал.
Я потратил немало времени на отладку кода, никаких очевидных проблем, обнаруженных до сих пор на стороне клиента, не наблюдалось повреждение памяти. Это однопоточное приложение, одновременно выполняющее один вызов, параллелизм на стороне клиента не является подозреваемым. Клиент работает в ядре Google Engine Engine, поэтому сеть, вероятно, тоже не проблема. Клиент gRPC постоянно обновляется с главной сетью github.
Любые предложения будут оценены. Если кто-то отлаживает идеи, которые также будут хороши. Использование valgrind, gdb, сокращение приложения до подмножества с воспроизводимыми результатами не помогло до сих пор, я не смог выяснить, в чем проблема. Проблема случайна и появляется иногда.
Дополнительное примечание от 17 мая 2016 года Было высказано предположение, что повторные попытки могут помочь решить проблему. К сожалению, повторные попытки не очень хорошо работают для нас, потому что нам придется переносить это на логику приложения. Мы можем легко перепробовать обновления, а это MutateRow звонки, и мы делаем это, это не потоковые вызовы и легко повторить попытку. Однако, как только итерация результатов запроса БД началась приложением, если он не выполняется, повторная попытка означает, что приложение должно повторно отправить запрос и снова запустить итерацию результатов. Это проблематично. Всегда можно рассмотреть изменение, которое заставило бы наши приложения читать весь результирующий набор сразу, а затем на уровне приложений итерации могут выполняться в памяти. Затем можно обрабатывать повторные попытки. Но это проблематично по всем причинам, таким как отставание памяти и задержки приложений. Мы хотим обработать результаты запроса БД, как только они появятся, а не когда все они находятся в памяти. При зависании вызова также добавляется тайм-аут к задержке вызова. Таким образом, повторные попытки итераций результатов очень дорогостоящие до такой степени, что они непрактичны.
Долгосрочные чтения определенно проблематичны. Клиент Java Bigtable отслеживает увиденное, а затем создает новый запрос, начиная с последних увиденных строк. Это тонкая проблема. Не стесняйтесь связаться со мной в sduskis at goog le dot com. –
Это не длинные запросы. Ошибки, которые я вижу, - это, как правило, первые прочитанные вызовы потока. И это не длинные сеансы. Я вижу эти сбои в течение минуты или двух тестового приложения. – ay60