Асинхронные вызовы

Какие виды таймаутов можно задавать в заголовке асинхронного вызова?

При отправке асинхронных вызовов возможно задать три вида таймаутов (через заголовок):

  • X-Health-Timeout — ограничение на проверку работоспособности сервиса с моделью, созданного при асинхронном запросе (значение устанавливается в секундах, по умолчанию — 120).

  • X-Request-Timeout— ограничение на время обработки асинхронного запроса (значение устанавливается в секундах, по умолчанию — 300).

  • X-Full-Live-Timeout — ограничение на общее время жизни сервиса с моделью, созданного при асинхронном запросе (значение устанавливается в секундах, по умолчанию — None).

В случае неуспешного выполнения вызова он повторяется, пока не исчерпает пять попыток или пока не превысит X-Full-Live-Timeout, если он был задан. После превышения одного из этих лимитов вызов помечается завершенным с ошибкой, повторная отправка не производится.

Общее время жизни равно сумме времени на проверку работоспособности и времени на обработку асинхронного запроса.

Почему могут возникать проблемы при выполнении асинхронного вызова?

Проблемы при выполнении асинхронного вызова могут происходить по следующим причинам:

  • Неправильный X_Health_Endpoint (по умолчанию он ожидается на /). Со стороны сервиса происходит пять попыток пересоздания. Если дальнейшие попытки неуспешны, возникает ошибка.

  • Время ответа деплоя на метод X_Health_Endpoint дольше, чем 120 секунд (таймаут проверки health по умолчанию). Со стороны сервиса происходит пять попыток пересоздания. Если дальнейшие попытки неуспешны, возникает ошибка.

  • Деплой слишком долго выполняет предикт (дольше X_Request_Timeout = 300 секунд по умолчанию). Со стороны сервиса происходит пять попыток пересоздания. Если дальнейшие попытки неуспешны, возникает ошибка.

Чтобы устранить возникшие проблемы, попробуйте создать асинхронный вызов, дополнительно указав заголовок X-Request-Timeout: 5000.

Запустили Evolution free tier
для Dev & Test
Получить