Сброс соединения по пиру: ajp_ilink_receive() не может получить заголовок
Я вижу это в журнале Liferay 6 (кластерное веб-приложение на основе Tomcat):
APR does not understand this error code: proxy: read response failed from [::1]:8009 (localhost)
The timeout specified has expired: ajp_ilink_receive() can't receive header
ajp_read_header: ajp_ilink_receive failed
[... the 3 lines above repeated many times ...]
Connection reset by peer: ajp_ilink_receive() can't receive header
APR does not understand this error code: proxy: read response failed from (null) (localhost)
ajp_read_header: ajp_ilink_receive failed
[... the 3 lines above repeated many times ...]
Веб-приложение становится непригодным для использования (веб-интерфейс не отвечает на веб-запросы), когда начинают появляться ошибки "Сброс соединения по одноранговым узлам".
Пока первая проблема (The timeout specified has expired) покрывается другим вопросом, что обычно вызывает вторую проблему (Connection reset by peer) а в чем разница между двумя проблемами?
1 ответ
На основании того, что другие пользователи задают этот вопрос на разных веб-сайтах, я предлагаю вам установить время ожидания соединения.
Пример ниже.
ProxyPass / ajp://localhost:8009/ timeout=600
https://stackoverflow.com/questions/32093534/ah01030-ajp-ilink-receive-cant-receive-header
Если в конфигурации уже указан тайм-аут соединения, другой пользователь обнаружит, если он изменил mod_proxy_ajp на mod_jk.
Я знаю, что таймауты обычно являются проблемой, однако после наблюдения аналогичной проблемы, когда размер был проблемой, установленной на самом коннекторе AJP, я думаю, что стоит опубликовать, чтобы включить ведение журнала доступа на вашем коннекторе, чтобы получить правильное ведение журнала (так как это не сделано по умолчанию в подсистемах коннектора jboss) или посмотрите на размер запросов, поскольку apache обычно устанавливает эти типы ограничений выше, чем те, которые могут быть по умолчанию для tomcat или jboss.
1.1.1.1.1 - - [19/ Дек /2019:14:33:53 -0500] "POST /app HTTP/1.0" 500 532 "-" "-"
Я включил комбинированную запись журнала Apache, поскольку считаю, что размер 532 является подсказкой на ответ от коннектора ajp. В моем случае 90% запросов приходили, за исключением больших объемов документов, которые мои разработчики смогли изучить и идентифицировать. Изучив значения по умолчанию для Apache и коннектора ajp в их документации, я решил удвоить "Максимальный размер сообщения" и получить запрос как 200. Я также заметил меньший размер в журналах доступа Apache, когда он был 200, поэтому вот почему Я думаю, что размер 532 важно отметить.