I am seeing this in Liferay 6 (a Tomcat-based clustered webapp)'s log:
APR does not understand this error code: proxy: read response failed from [::1]:8009 (localhost)
The timeout specified has expired: ajp_ilink_receive() can't receive header
ajp_read_header: ajp_ilink_receive failed
[... the 3 lines above repeated many times ...]
Connection reset by peer: ajp_ilink_receive() can't receive header
APR does not understand this error code: proxy: read response failed from (null) (localhost)
ajp_read_header: ajp_ilink_receive failed
[... the 3 lines above repeated many times ...]
The webapp becomes unusable (the web UI does not respond to web requests) when the "Connection reset by peer" errors start appearing.
While the first problem (The timeout specified has expired
) is covered by another question, what usually causes the second problem (Connection reset by peer
), and what is the difference between the two problems?
Based on this question being asked by others on different websites, I will suggest you set the connection timeout.
Example is below.
https://stackoverflow.com/questions/32093534/ah01030-ajp-ilink-receive-cant-receive-header
mod_proxy_ajp (70007)The timeout specified has expired: ajp_ilink_receive() can't receive header
If you already have a connection timeout specified in the configuration, another user found if they changed mod_proxy_ajp to mod_jk.
https://community.atlassian.com/t5/Jira-questions/503-Error-ajp-read-header-ajp-ilink-receive-failed/qaq-p/130248
I know timeouts are normally the issue, however after observing a similar issue where the size was the issue set on the AJP connector itself, I think its worth posting to enable access logging on your connector to get proper logging (as this isn't done by default on jboss connector subsystems) or look at the size of the requests as apache normally sets these types of limits higher than what tomcat or jboss might be by default.
1.1.1.1.1 - - [19/Dec/2019:14:33:53 -0500] "POST /app HTTP/1.0" 500 532 "-" "-"
I've include an Apache combined log entry as I believe the 532 size is a hint at the response from the ajp connector. In my case 90% of requests came through except for bigger document payloads that my developers was able to examine and identify himself. After reviewing Apache and the ajp connector defaults within their documentation, I decided to double the "Max Post Size" and get the request through as a 200. I also observed a lower size in the Apache access logs when it was a 200 so that's why I think the 532 size is important to note.