Apache получает запросы на порт: 80 и проксирует их на Jetty через порт: 8080
The proxy server received an invalid response from an upstream server
The proxy server could not handle the request GET /.
Моя дилемма: Все нормально работает как обычно (обрабатываются быстрые запросы, запросы длиной в несколько секунд или несколько десятков секунд хорошо). Проблемы происходить когда обработка запроса занимает много времени (несколько минут?).
Если я вместо этого отправлю запрос прямо на причал в порту: 8080 запрос обработан нормально. Итак, проблема в том скорее всего сидеть где-то между Apache и Jetty, где я использую mod_proxy. Как это решить?
Я уже пробовал некоторые "хитрости" связанных с настройками KeepAlive, безуспешно. Вот моя текущая конфигурация, есть предложения?
#keepalive Off ## I have tried this, does not help
#SetEnv force-proxy-request-1.0 1 ## I have tried this, does not help
#SetEnv proxy-nokeepalive 1 ## I have tried this, does not help
#SetEnv proxy-initial-not-pooled 1 ## I have tried this, does not help
KeepAlive 20 ## I have tried this, does not help
KeepAliveTimeout 600 ## I have tried this, does not help
ProxyTimeout 600 ## I have tried this, does not help
NameVirtualHost *:80
<VirtualHost _default_:80>
ServerAdmin webmaster@mydomain.fi
ServerName www.mydomain.fi
ServerAlias mydomain.fi mydomain.com mydomain www.mydomain.com
ProxyRequests On
ProxyVia On
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyRequests Off
ProxyPass / http://www.mydomain.fi:8080/ retry=1 acquire=3000 timeout=600
ProxyPassReverse / http://www.mydomain.fi:8080/
RewriteEngine On
RewriteCond %{SERVER_NAME} !^www\.mydomain\.fi
RewriteRule /(.*) http://www.mydomain.fi/$1 [redirect=301L]
ErrorLog /var/log/apache2/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/access.log combined
ServerSignature On
</VirtualHost>
Вот также журнал отладки неудачного запроса:
74.125.43.99 - - [29/Sep/2010:20:15:40 +0300] "GET /?wicket:bookmarkablePage=newWindow:com.mydomain.view.application.reports.SaveReportPage HTTP/1.1" 502 355 "https://www.mydomain.fi/?wicket:interface=:0:2:::" "Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10"
[Wed Sep 29 20:20:40 2010] [error] [client 74.125.43.99] proxy: error reading status line from remote server www.mydomain.fi, referer: https://www.mydomain.fi/?wicket:interface=:0:2:::
[Wed Sep 29 20:20:40 2010] [error] [client 74.125.43.99] proxy: Error reading from remote server returned by /, referer: https://www.mydomain.fi/?wicket:interface=:0:2:::
Я решил проблему. В Keepalive=On следует вставить в ProxyPass строка конфигурации:
ProxyPass / http://www.dom.fi:8080/ retry=1 acquire=3000 timeout=600 Keepalive=On
Видеть, что
Keepalive=On
там? Это критично;)
Вы пробовали установить setenv proxy-initial-not-pooled 1?
Ссылка Вот
Эта ошибка также может возникнуть, если в конце URL-адреса прокси-сервера не указано /. Либо оба пути должны заканчиваться / или ни то, ни другое.
Посмотрев на журнал, вы увидите, что время ожидания истекает через 5 минут (= 300 секунд). Очень долго ждать ответа. Когда вы обращаетесь к серверу Jetty напрямую, действительно ли этому ресурсу требуется столько времени, чтобы произвести ответ?
Если пять минут действительно находятся в пределах возможного времени ответа, вы можете попробовать настроить директиву конфигурации ProxyTimeout.
В зависимости от настройки вашей сети вполне может быть, что нет причин даже пытаться использовать какую-либо систему поддержки активности (есть ли брандмауэр между сервером приложений и прокси-сервером, который может быть настроен на отбрасывание сеансов, которые простаивают слишком долго?) , но ProxyTimeout повлияет на поведение самого прокси.
Если тот же прокси-сервер также обслуживает другие серверные части, было бы лучше сохранить текущий ProxyTimeout и настроить тайм-аут в директиве ProxyPass (см. Документацию mod_proxy).
Если, однако, ответы без прокси-сервера постоянно являются чем-то намного меньшим, чем пять минут, которые здесь рассматриваются как предел отсечения, тогда действительно может быть какое-то странное вмешательство между прокси и сервером приложений, но вы не предоставляете ничего из значение для определения того, что это может быть.
Для меня удаление значения заголовка под названием Transfer-Encoding" (binary) в моем серверном приложении (PHP) проблема решена для:
[proxy_http: error] [pid 17623] (22) Недействительный аргумент: [client 127.0.0.1:44929] AH01102: ошибка чтения строки состояния с удаленного сервера 0.0.0.0:80
Все другие предложения, такие как SetEnv proxy-initial-not-pooled или Keep-Alive не.
Если вышеперечисленные решения не работают, вы можете попробовать включить все свои модули apache, чтобы убедиться, что нет нужного вам модуля, который каким-то образом был случайно отключен.
Например, я обнаружил, что причина моей проблемы заключалась в замене всех экземпляров #LoadModule на LoadModule во всех моих файлах конфигурации Apache. Поскольку это решило проблему для меня, я знал, что моя проблема заключалась не в отсутствии аргумента директивы KeepAlive, а в том, что моя проблема заключалась в отсутствии зависимости.
Помните, что файлы .so - это в основном статические библиотеки. Включенный модуль не означает, что он будет использоваться, но отключение одного из модулей означает, что его нельзя использовать, и, следовательно, все, что от него зависит, обязательно выйдет из строя.
Примечание: этот ответ получил несколько отрицательных голосов из-за того, что мой первоначальный ответ, казалось, предлагал оставить все модули включенными навсегда. Хотя теоретически вы можете сделать это, не обязательно что-либо ломая, это явно не лучшее практическое решение.
Поэтому, пожалуйста, поймите, я предлагаю это просто как шаг по устранению неполадок, а не как окончательное решение.
Также обратите внимание: я использую специальный проект git для отслеживания всех файлов конфигурации apache на моем локальном компьютере. Таким образом, я могу выполнять такого рода глобальные операции поиска и замены в моем рабочем каталоге конфигурации apache в качестве шага по устранению неполадок. Если включение всех модулей прошло успешно, попробуйте снова отключить их по одному и перезапустить apache между ними, пока не найдете, какой именно модуль необходимо оставить включенным. Как только вы это выяснили, сбросьте репо в исходное состояние и включите только тот модуль, который должен оставаться включенным.
Вы также обнаружите, что использование git для отслеживания ваших файлов конфигурации apache очищает эти каталоги, поскольку вам больше не понадобятся эти старомодные файлы .bak и .default.