Прочитать на английском

Поделиться через


Сбои RPC и http.postBuffer

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

При возникновении RPC failed ошибки во время git pushвыполнения таких ошибок, как:

  • error: RPC failed; result=22, HTTP code = 404
  • error: RPC failed; result=22, HTTP code = 411
  • Unable to rewind rpc post data - try increasing http.postBuffer error: RPC failed; result=56, HTTP code = 0

... и выполните поиск справки на форумах Stack Overflow или MSDN, вы увидите множество старых рекомендаций для заданияhttp.postBuffer.

Не делайте этого! По крайней мере, не слепо. Сначала ознакомьтесь с предложениями в этой статье.

Обновление Git

Если вы по-прежнему работаете с клиентом Git версии 2.8 или более ранней, сначала следует обновить Git. Существуют исправления ошибок в более новых версиях Git, которые должны не учитывать необходимость установки http.postBuffer.

У нас было достаточно запросов на поддержку от внутренних пользователей и внешних клиентов, связанных с ошибками в более ранних версиях Git, которые мы решили добавить напоминание на стороне сервера в Azure DevOps Services/TFS.

c:\mydir>git fetch
remote: Microsoft (R) Visual Studio (R) Team Services
remote: We noticed you're using an older version of Git. For a better experience, upgrade to the latest version at https://git-scm.com/downloads
remote: Found 4 objects to send. (6 ms)
Unpacking objects: 100% (4/4), done.

Проверка исправлений

Проверьте, применяются ли эти исправления, если сервер TFS работает под управлением Windows 2012 R2 или более ранней версии:

Проверьте, используется ли прокси-сервер или подсистема балансировки нагрузки

Если вы используете ужасный прокси-сервер, который ошибается или не поддерживает фрагментированную кодировку, вы увидите ошибки для больших push-уведомлений. То же самое может произойти, если вы настроили TFS за неправильно настроенной подсистемой балансировки нагрузки. Если та же отправка завершается успешно при обходе прокси-сервера или обходе подсистемы балансировки нагрузки (например, путем отправки в localhost с самого сервера), то исправьте прокси-сервер или подсистему балансировки нагрузки.

Что делать, если мой прокси-сервер или подсистема балансировки нагрузки нарушена, но у меня нет никакого контроля над ним?

Это единственный сценарий, который мы видели, где параметр http.PostBuffer полезен для более новых версий Git.

Вопросы http.postBuffer

Вреден ли параметр http.postBuffer ?

В нашем опыте это более ненужным, чем вредным, но есть несколько негативных побочных эффектов:

  • Увеличение по умолчанию может увеличить задержку для больших push-уведомлений (так как клиент будет буферизуть HTTP-запрос в большие блоки).
  • Если задать размер блока HTTP для HTTP-сервера (например maxAllowedContentLength , и maxRequestLength web.config для серверов TFS), все отправки больше, чем ограничение размера блока, начнется сбоем.

Разделы справки отменить настройкуhttp.postBuffer, если она уже задана?

Чтобы проверка, если он задан, выполните следующую команду:

git config --show-origin --get-all http.postBuffer

Возможно, потребуется отменить его в глобальном .gitconfig файле:

git config --global --unset http.postBuffer

Кроме того, на уровне .git/config репозитория (который переопределяет глобальный параметр):

git config --local --unset http.postBuffer