0

For a long time I had 3 Java web apps running on box with Parallels Plesk panel. Everything was fine until yesterday. Without any reason I started to get 500 on all apps running throe mod_jk - php apps are fine.

I tuned log level to debug for both apache and mod_jk - nothing beside this in mod_jk log is suspicious:

[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

and in access log I found:

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"

I am running:

  • Plesk 9.5.4
  • Apache 2.2
  • Tomcat 6.x

worker configuration is as follows:

# 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

Any ideas? I hate Plesk - but it was not my choice - I just need to survive with it until we will be able to move to other hosting provider.

In Tomcat I see line indicating JK startup:

INFO: JK: ajp13 listening on /188.165.22.102:8009

In mod_jk.log there is information about creating worker:

[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

Any ideas where to look for more info on such thing?

Konrad Pawlus
  • 133
  • 1
  • 1
  • 7
  • Most bizarre Plesk behavior I saw so far - and I saw a lot of those :) Although one of domains hosted on this box is valid until 2013 Plesk suspended it... and after this all workers stopped to work. Removing worker responsible for app on this domain solved problem... I am not even trying to find-out why... So in case you will spend 12 hours on same problem - check first if you have some domains suspended. I will answer my question in 8 hours or so :) – Konrad Pawlus Jan 25 '12 at 20:41

1 Answers1

0

Most bizarre Plesk behavior I saw so far - and I saw a lot of those :)

Although one of domains hosted on this box is valid until 2013 Plesk suspended it... and after this all workers stopped to work. Removing worker responsible for app on this domain solved problem...

I am not even trying to find-out why...

So in case you will spend 12 hours on same problem - check first if you have some domains suspended.

Konrad Pawlus
  • 133
  • 1
  • 1
  • 7