#c #linux #google-text-to-speech
#c #linux #google-преобразование текста в речь
Вопрос:
Я запускал нагрузочный тест, который продолжает отправлять запросы в Google Text-to-Speech. Замечено, что клиент будет получать кучу ошибок с кодом 16 (НЕ ПРОШЕДШИЙ проверку ПОДЛИННОСТИ) на почасовой основе. Ошибки будут длиться чуть более одной минуты, а затем все вернется к нормальной жизни. Соответственно, я бы увидел некоторые журналы grpc, такие как:
I0418 15:56:42.058182865 4182 call.cc: 777] 1: {«создано»:»@1555617402.058118998″, «описание»: «Ошибка, полученная от однорангового узла», «файл»: «src / core / lib / surface / call.cc», «file_line»: 1099, «grpc_message»: «Запрос был отклонен неверные учетные данные для аутентификации. Ожидаемый токен доступа OAuth 2, файл cookie для входа или другие действительные учетные данные для аутентификации. См https://developers.google.com/identity/sign-in/web/devconsole-project .»,»grpc_status»: 16} I0418 15:56:42.058221929 4182 completion_queue.cc:691] cq_end_op_for_next(cq = 0x1fa9a480, tag = 0x1fa96948, ошибка = «Нет ошибки», выполнено = 0x7fba193e52a0, выполненный аргумент=0x1fa96a90, хранилище=0x1fa96a98)
И я использую grpc::GoogleDefaultCredentials.
Комментарии:
1. На самом деле это не похоже на реальную ошибку, которую вы получили бы от surface API, а скорее на внутренний журнал из нашего кода. Есть ли у вас какие-либо негативные последствия для самого вашего программного обеспечения? Если нет, это может быть просто чем-то, что нужно игнорировать. Журналы отладки grpc могут быть очень болтливыми, и не все в них имеют отношение к конечному пользователю.
2. Ошибка была вызвана тем фактом, что системные часы клиента отставали от реального времени примерно на 15 минут. После включения службы ntpd ошибка исчезла. Речь идет о токене доступа oauth, срок действия которого неожиданно истек из-за неправильных системных часов клиента.
3. Ах, да! Это сделало бы это 🙂 Синхронизация часов важна для аутентификации.