Score:0

How can I test an ajp worker (tomcat10, apache 2.4.6)?

cn flag

I have a simple server setup:

  1. Apache 2.4.6
  2. JK Worker for talking with Tomcat, where a REST service is living
  3. Tomcat 10

Virtual Host

In my virtual host file I have this configuration (snippet in <VirtualHost *:443>):

<Directory "/var/www/frontends">
    Require all granted

    RewriteEngine On

    # [...]
    RewriteRule co2avatar-app/sdp-api$ sdp-api/test/ [PT]
    RewriteRule co2avatar-app/sdp-api/(.*)$ sdp-api/$1 [PT]

    # anything else to index.html
    RewriteRule co2avatar-app/(.+) co2avatar-app/index.html [L]
</Directory>

# worker definition
JkMount /sdp-api/* ajp13_worker_prod
JkMount /sdp-api ajp13_worker_prod

Workers

# workers.properties -

# workers.tomcat_home=/opt/tomcat/latest/

#
# workers.java_home should point to your Java installation. Normally
# you should have a bin and lib directories beneath it.
#
workers.java_home=/usr/lib/jvm/

ps=/
worker.list=ajp13_worker_prod,ajp13_worker_test,ajp13_worker_tomcat10_test,ajp_worker_tomcat10_prod

#
#------ ajp13_worker WORKER DEFINITION ------------------------------
#---------------------------------------------
#
worker.ajp13_worker_prod.port=8009
worker.ajp13_worker_prod.host=localhost
worker.ajp13_worker_prod.type=ajp13

worker.ajp13_worker_test.port=8010
worker.ajp13_worker_test.host=localhost
worker.ajp13_worker_test.type=ajp13

worker.ajp13_worker_tomcat10_test.port=8020
worker.ajp13_worker_tomcat10_test.host=localhost
worker.ajp13_worker_tomcat10_test.type=ajp13

worker.ajp13_worker_tomcat10_prod.port=8019
worker.ajp13_worker_tomcat10_prod.host=localhost
worker.ajp13_worker_tomcat10_prod.type=ajp13

# we do not use load balancing at all.

I should add that the ajp13_worker_prod worker points to a service in a Tomcat 9 instance, the ajp13_worker_tomcat10_prod worker to a Tomcat 10 instance. But this works very fine for a different virtual host (which is effectively the test system).

Everything works fine until I change the lines

JkMount /sdp-api/* ajp13_worker_prod
JkMount /sdp-api ajp13_worker_prod

to

JkMount /sdp-api/* ajp13_worker_tomcat10_prod
JkMount /sdp-api ajp13_worker_tomcat10_prod

The services in Tomcat are working fine, I can reach them via curl http://localhost:6085/[...]. So the ports are open for usage from localhost.

But I cannot reach them from outside, via Apache. Here I am getting a 500 with The server encountered an internal error or misconfiguration and was unable to complete your request.

I scanned all possible error log files, but I cannot see problem, especially not in the Apache logs.

Is there any way to test an JK worker?

Is there any way to test the Tomcat Connector?

It looks like this in server.xml: <Connector port="8019" proxyName="co2avatar.org" proxyPort="80" protocol="AJP/1.3" redirectPort="8443" secretRequired="false" />. The HTTP connector works, but maybe not this one? There is a problem between Apache (the ajp worker) and Tomcat, but just firing request against Apache does not help yet.

(Beginner question:) Is it possible to restart the JK module only?

Here is an excerpt from Apache error_log (there is nothing in mod_jk.log):

[jk:warn] [pid 1286] No JkShmFile defined in httpd.conf. Using default /etc/httpd/logs/jk-runtime-status
[slotmem_shm:debug] [pid 1286] mod_slotmem_shm.c(448): AH02301: attach looking for /run/httpd/slotmem-shm-mod_heartmonitor.shm
[lbmethod_heartbeat:notice] [pid 1286] AH02282: No slotmem from mod_heartmonitor
[ssl:debug] [pid 1286] ssl_engine_pphrase.c(181): AH02199: SSL not enabled on vhost h2862201.stratoserver.net:80, skipping SSL setup
[ssl:debug] [pid 1286] ssl_engine_pphrase.c(239): AH02202: Init: Read server certificate from '/etc/letsencrypt/live/co2-avatar.com/cert.pem'
[ssl:debug] [pid 1286] ssl_engine_pphrase.c(239): AH02202: Init: Read server certificate from '/etc/letsencrypt/live/co2-avatar.com/cert.pem'
[ssl:debug] [pid 1286] ssl_engine_pphrase.c(239): AH02202: Init: Read server certificate from '/etc/letsencrypt/live/co2-avatar.com/fullchain.pem'
[ssl:debug] [pid 1286] ssl_engine_pphrase.c(239): AH02202: Init: Read server certificate from '/etc/letsencrypt/live/co2-avatar.com/cert.pem'
[ssl:debug] [pid 1286] ssl_engine_pphrase.c(239): AH02202: Init: Read server certificate from '/etc/letsencrypt/live/co2-avatar.com/cert.pem'
[socache_shmcb:debug] [pid 1286] mod_socache_shmcb.c(391): AH00821: shmcb_init allocated 512000 bytes of shared memory
[socache_shmcb:debug] [pid 1286] mod_socache_shmcb.c(407): AH00822: for 511912 bytes (512000 including header), recommending 32 subcaches, 88 indexes each
[socache_shmcb:debug] [pid 1286] mod_socache_shmcb.c(440): AH00824: shmcb_init_memory choices follow
[socache_shmcb:debug] [pid 1286] mod_socache_shmcb.c(442): AH00825: subcache_num = 32
[socache_shmcb:debug] [pid 1286] mod_socache_shmcb.c(444): AH00826: subcache_size = 15992
[socache_shmcb:debug] [pid 1286] mod_socache_shmcb.c(446): AH00827: subcache_data_offset = 2128
[socache_shmcb:debug] [pid 1286] mod_socache_shmcb.c(448): AH00828: subcache_data_size = 13864
[socache_shmcb:debug] [pid 1286] mod_socache_shmcb.c(450): AH00829: index_num = 88
[socache_shmcb:info] [pid 1286] AH00830: Shared memory socache initialised
[ssl:info] [pid 1286] AH01887: Init: Initializing (virtual) servers for SSL
[ssl:debug] [pid 1286] ssl_engine_init.c(1502): Init: SSL server IP/port overlap: h2862201.stratoserver.net:443 (/etc/httpd/conf.d/ssl.conf:57) vs. co2-avatar.com:443 (/etc/httpd/conf.d/vhost-le-ssl.conf:4)
[ssl:debug] [pid 1286] ssl_engine_init.c(1502): Init: SSL server IP/port overlap: gitlab.sustainable-data-platform.org:443 (/etc/httpd/conf.d/gitlab-le-ssl.conf:2) vs. co2-avatar.com:443 (/etc/httpd/conf.d/vhost-le-ssl.conf:4)
[ssl:debug] [pid 1286] ssl_engine_init.c(1502): Init: SSL server IP/port overlap: co2avatar.org:443 (/etc/httpd/conf.d/co2avatar.conf:66) vs. co2-avatar.com:443 (/etc/httpd/conf.d/vhost-le-ssl.conf:4)
[ssl:warn] [pid 1286] AH02292: Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
[ssl:info] [pid 1286] AH01876: mod_ssl/2.4.6 compiled against Server: Apache/2.4.6, Library: OpenSSL/1.0.2k
[proxy:debug] [pid 1292] proxy_util.c(1843): AH00925: initializing worker proxy:reverse shared
[proxy:debug] [pid 1292] proxy_util.c(1888): AH00927: initializing worker proxy:reverse local
[proxy:debug] [pid 1292] proxy_util.c(1939): AH00931: initialized single connection worker in child 1292 for (*)
[proxy:debug] [pid 1293] proxy_util.c(1843): AH00925: initializing worker proxy:reverse shared
[proxy:debug] [pid 1293] proxy_util.c(1888): AH00927: initializing worker proxy:reverse local
[proxy:debug] [pid 1293] proxy_util.c(1939): AH00931: initialized single connection worker in child 1293 for (*)
[proxy:debug] [pid 1295] proxy_util.c(1843): AH00925: initializing worker proxy:reverse shared
[proxy:debug] [pid 1295] proxy_util.c(1888): AH00927: initializing worker proxy:reverse local
[proxy:debug] [pid 1295] proxy_util.c(1939): AH00931: initialized single connection worker in child 1295 for (*)
[mpm_prefork:notice] [pid 1286] AH00163: Apache/2.4.6 (CentOS) mod_jk/1.2.48 OpenSSL/1.0.2k-fips PHP/7.2.29 configured -- resuming normal operations
[mpm_prefork:info] [pid 1286] AH00164: Server built: Nov 16 2020 16:18:20
[core:notice] [pid 1286] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[mpm_prefork:debug] [pid 1286] prefork.c(1005): AH00165: Accept mutex: sysvsem (default: sysvsem)
[proxy:debug] [pid 1294] proxy_util.c(1843): AH00925: initializing worker proxy:reverse shared
[proxy:debug] [pid 1294] proxy_util.c(1888): AH00927: initializing worker proxy:reverse local
[proxy:debug] [pid 1294] proxy_util.c(1939): AH00931: initialized single connection worker in child 1294 for (*)
[proxy:debug] [pid 1296] proxy_util.c(1843): AH00925: initializing worker proxy:reverse shared
[proxy:debug] [pid 1296] proxy_util.c(1888): AH00927: initializing worker proxy:reverse local
[proxy:debug] [pid 1296] proxy_util.c(1939): AH00931: initialized single connection worker in child 1296 for (*)
[proxy:debug] [pid 1378] proxy_util.c(1843): AH00925: initializing worker proxy:reverse shared
[proxy:debug] [pid 1378] proxy_util.c(1888): AH00927: initializing worker proxy:reverse local
[proxy:debug] [pid 1378] proxy_util.c(1939): AH00931: initialized single connection worker in child 1378 for (*)
[proxy:debug] [pid 1408] proxy_util.c(1843): AH00925: initializing worker proxy:reverse shared
[proxy:debug] [pid 1408] proxy_util.c(1888): AH00927: initializing worker proxy:reverse local
[proxy:debug] [pid 1408] proxy_util.c(1939): AH00931: initialized single connection worker in child 1408 for (*)
[proxy:debug] [pid 1859] proxy_util.c(1843): AH00925: initializing worker proxy:reverse shared
[proxy:debug] [pid 1859] proxy_util.c(1888): AH00927: initializing worker proxy:reverse local
[proxy:debug] [pid 1859] proxy_util.c(1939): AH00931: initialized single connection worker in child 1859 for (*)
[proxy:debug] [pid 15109] proxy_util.c(1843): AH00925: initializing worker proxy:reverse shared
[proxy:debug] [pid 15109] proxy_util.c(1888): AH00927: initializing worker proxy:reverse local
[proxy:debug] [pid 15109] proxy_util.c(1939): AH00931: initialized single connection worker in child 15109 for (*)
[proxy:debug] [pid 17029] proxy_util.c(1843): AH00925: initializing worker proxy:reverse shared
[proxy:debug] [pid 17029] proxy_util.c(1888): AH00927: initializing worker proxy:reverse local
[proxy:debug] [pid 17029] proxy_util.c(1939): AH00931: initialized single connection worker in child 17029 for (*)
Score:0
cn flag

Well, it is embarrasing, but I've used a wrong name in my workers list.

ajp_worker_tomcat10_prod instead of ajp13_worker_tomcat10_prod.

The interesting part is that there was no error message like worker not found or worker has no config. Just the weird message from Apache and nothing in mod_jk.log or Apache's error.log.

This might also be a configuration problem.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.