When configuring a new Web application based on the new versions of Apache-2.4.46+ and Tomcat-9.0.45+, use the same configuration files as the previous versions when connecting with Mod_jk. When Apache JSP file requests are triggered to Mod_jk and further passed to Tomcat for processing, they start reporting an error message such as Connection Failed to Backend Service.
Apache is unable to connect to the Tomcat service via mod_jk. Testing Apache and Tomcat separately, such as requesting a non-JSP file separately or requesting a corresponding JSP file on Tomcat port 8080, will handle the corresponding request normally. Based on this, we figured out that the problem was mod_jk. What went wrong?
We turn on the corresponding verbose logging in Apache /conf/extra/httpd-jk.conf.
\# Our JK log level (trace,debug,info,warn,error)
JkLogLevel trace
Output process records for all steps. The log soon reported that it was unable to connect to the :: 1:8,009 service.
The problem seemed to manifest itself at once. Due to the configuration of IPv4 and IPv6 dual-stack network addresses, the resolution of localhost at some service level may be IPv4 address :127.0.0.1 or IPv6 address ::1. For some reason, the localhost hostname resolves as an IPv6 address in Apache mod_jk, while the Tomcat program resolves as an IPv4 address.
Quite so the worker in the mod_jk configuration: apache/conf/extra workers. The properties:
worker.balancer.balance_workers=node1 worker.node1.reference=worker.template worker.node1.host=localhost \ # worker. Node1. Host = 127.0.0.1 worker. The node1. Port = 8009
In Tomcat, the service might start on 127.0.0.1:8009, so both sides would be missed due to V4 or V6 of the IP address. 1) modify the hosts file on the system to disambiguate the host name localhost, only for the traditional 127.0.0.1 address, but for the ::1 address, and name it localhost-ipv6; 2) modify the host name to disambiguate the host name localhost. Or 2) in the Apache and Tomcat configuration files, instead of using hostnames, use explicit and specific IP addresses. After some work, we disambiguously disambiguated localhost and just pointed to 127.0.0.1, and in Tomcat/conf/server.xml:
< Connector AJP protocol = “/ 1.3”
Port = "8009"Address = “127.0.0.1 redirectPort =” 8443 “/ >”
Specific IPv4 addresses have also been specified so that they should be able to connect as expected. After this operation, mod_jk will no longer report an error saying ::1:8009 or 127.0.1:8009 can’t connect, but still can’t connect! Connection failed to backend service… Connection failed to backend service… In error state or wrong port… .
Unlike before, this time it clearly shows Socket Connected, the connection has been created and is no longer a network layer issue. – Added timeout during cping/cpong… , according to these new error information, continue to rely on the help of search engines, mining relevant information. The new version of Tomcat enabled the new configuration by default, but failed to provide specific and explicit instructions in the log message.
(-r /v2SS) There was a change in Tomcat last year (from version 8.5.51 and version 9.0.31), which introduced a secretRequired attribute to the AJP connector with a default of true (cf. documentation). Hence you can either:
add a shared secret between the AJP connector and mod_jk
or add secretRequired=”false” to the AJP connector.
To be straightforward, Tomcat-9.0.31+, which was enabled by default for the guidance of secretreguidance =true, was not mentioned in the corresponding sample configuration defaults. There was no mention in the error log that the problem was due to secretre-guidance. To resolve this problem, manual configuration is required: 1) add a shared security key between the AXP and mod_jk, or 2) disable this function by setting secretre-guidance =false in the AXP.
Oddly enough, this AGP was enabled by default for the guidance of secretre-guidance =true, while mod_jk was not enabled by default, for the guidance of setting secretre-guidance =false, so there was no way for the two sides to communicate. Unfortunately, this mismatch occurred at the software level and was not clearly identified in the error message and should be corrected later.