В течение долгого времени у меня было 3 веб-приложения Java, работающих на компьютере с панелью Parallels Plesk. До вчерашнего дня все было хорошо. Без всякой причины я начал получать 500 во всех приложениях, работающих через mod_jk - приложения php в порядке.
Я настроил уровень журнала для отладки как для apache, так и для mod_jk - кроме этого в журнале mod_jk нет ничего подозрительного:
[Wed Jan 25 19:57:49 2012][5147:0000] [debug] map_uri_to_worker::jk_uri_worker_map.c (449): Attempting to map URI '/' from 2 maps
[Wed Jan 25 19:57:49 2012][5147:0000] [debug] map_uri_to_worker::jk_uri_worker_map.c (461): Attempting to map context URI '/*'
[Wed Jan 25 19:57:49 2012][5147:0000] [debug] map_uri_to_worker::jk_uri_worker_map.c (475): Found a wildchar match seomanagonode -> /*
[Wed Jan 25 19:57:49 2012][5147:0000] [debug] jk_handler::mod_jk.c (1839): Into handler jakarta-servlet worker=seomanagonode r->proxyreq=0
[Wed Jan 25 19:57:49 2012][5147:0000] [debug] wc_get_worker_for_name::jk_worker.c (111): did not find a worker seomanagonode
[Wed Jan 25 19:57:49 2012][5147:0000] [info] jk_handler::mod_jk.c (1993): Could not find a worker for worker name=seomanagonode
и в журнале доступа я нашел:
195.150.128.28 - - [25/Jan/2012:08:45:58 +0100] "GET / HTTP/1.1" 500 806 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Ubuntu/11.04 Chromium/14.0.835.202 Chrome/14.0.835.202 Safari/535.1"
Я бегаю:
Конфигурация рабочего выглядит следующим образом:
# seomanago.pl
worker.seomanagonode.port=8009
worker.seomanagonode.host=seomanago.pl
worker.seomanagonode.type=ajp13
worker.seomanagonode.ping_mode=A
worker.seomanagonode.socket_timeout=60
worker.seomanagonode.prepost_timeout=10000
worker.seomanagonode.connect_timeout=10000
worker.seomanagonode.connection_pool_size=200
worker.seomanagonode.connection_pool_timeout=300
worker.seomanagonode.retries=20
Любые идеи? Я ненавижу Plesk - но это был не мой выбор - мне просто нужно выжить с ним, пока мы не сможем перейти к другому хостинг-провайдеру.
В Tomcat я вижу строку, указывающую на запуск JK:
INFO: JK: ajp13 listening on /188.165.22.102:8009
В mod_jk.log есть информация о создании воркера:
[Wed Jan 25 18:45:52 2012][12306:0000] [debug] build_worker_map::jk_worker.c (236): creating worker seomanagonode
[Wed Jan 25 18:45:52 2012][12306:0000] [debug] wc_create_worker::jk_worker.c (141): about to create instance seomanagonode of ajp13
[Wed Jan 25 18:45:52 2012][12306:0000] [debug] wc_create_worker::jk_worker.c (154): about to validate and init seomanagonode
[Wed Jan 25 18:45:52 2012][12306:0000] [debug] ajp_validate::jk_ajp_common.c (1806): worker seomanagonode contact is 'seomanago.pl:8009'
[Wed Jan 25 18:45:52 2012][12306:0000] [debug] ajp_init::jk_ajp_common.c (1895): setting socket keepalive to 0
[Wed Jan 25 18:45:52 2012][12306:0000] [debug] ajp_init::jk_ajp_common.c (1934): setting socket timeout to 60
[Wed Jan 25 18:45:52 2012][12306:0000] [debug] ajp_init::jk_ajp_common.c (1938): setting socket buffer size to 0
[Wed Jan 25 18:45:52 2012][12306:0000] [debug] ajp_init::jk_ajp_common.c (1942): setting connection recycle timeout to 0
[Wed Jan 25 18:45:52 2012][12306:0000] [debug] ajp_init::jk_ajp_common.c (1946): setting cache timeout to 0
[Wed Jan 25 18:45:52 2012][12306:0000] [debug] ajp_init::jk_ajp_common.c (1950): setting connect timeout to 10000
[Wed Jan 25 18:45:52 2012][12306:0000] [debug] ajp_init::jk_ajp_common.c (1954): setting reply timeout to 0
[Wed Jan 25 18:45:52 2012][12306:0000] [debug] ajp_init::jk_ajp_common.c (1958): setting prepost timeout to 10000
[Wed Jan 25 18:45:52 2012][12306:0000] [debug] ajp_init::jk_ajp_common.c (1962): setting recovery opts to 0
[Wed Jan 25 18:45:52 2012][12306:0000] [debug] ajp_init::jk_ajp_common.c (1966): setting number of retries to 20
[Wed Jan 25 18:45:52 2012][12306:0000] [debug] ajp_create_endpoint_cache::jk_ajp_common.c (1843): setting connection cache size to 200
[Wed Jan 25 18:45:52 2012][12306:0000] [debug] build_worker_map::jk_worker.c (248): removing old seomanagonode worker
Есть идеи, где найти дополнительную информацию о таких вещах?
Самое странное поведение Plesk, которое я видел до сих пор - и я видел много таких :)
Хотя один из доменов, размещенных на этом ящике, действителен до 2013 года, Plesk приостановил его ... и после этого все рабочие перестали работать. Удаление работника, ответственного за приложение в этом домене, решило проблему ...
Я даже не пытаюсь понять, почему ...
Так что, если вы потратите 12 часов на решение одной и той же проблемы - сначала проверьте, приостановлены ли у вас некоторые домены.