I'm using apache on one machine to serve requests to jboss on another machine. Everything works fine when I startup jboss and I'm able to access the web app, but after a few hours I eventually start getting "The proxy server received an invalid response from an upstream server" errors. If I restart jboss then everything works fine again, but several hours later I have the same issue...
我在一台机器上使用apache来为另一台机器上的jboss提供请求。当我启动jboss并且我能够访问Web应用程序时,一切正常,但几个小时后我终于开始收到“代理服务器收到来自上游服务器的无效响应”错误。如果我重新启动jboss然后一切正常,但几个小时后我有同样的问题......
Does anybody know what could be causing this issue? I don't have access to the apache logs at this time (I should in a few hours) but it seems to be something with jboss since restarting it is the temporary fix.
有谁知道可能导致这个问题的原因是什么?我此时无法访问apache日志(我应该在几个小时内),但它似乎与jboss有关,因为重新启动它是临时修复。
I'm using jboss4.2.3 and apache 1.3 with mod_jk. I'm not finding any errors in the jboss logs and the app I'm trying to reach isn't doing anything that takes a long time. The main page is just a simple login page. I have ports 8009 and 8080 open for communication between the app server and web server. I don't know what configuration is wrong.
我正在使用jboss4.2.3和apache 1.3与mod_jk。我没有在jboss日志中找到任何错误,我想要达到的应用程序没有做任何需要很长时间的事情。主页面只是一个简单的登录页面。我打开了端口8009和8080,用于在应用服务器和Web服务器之间进行通信。我不知道配置有什么问题。
4 个解决方案
#1
This sounds to me like mod_jk in Apache is getting out of sync with the AJP connector in JBoss. The AJP protocol uses persistent, re-used connections between web server and app server, and if the protocol is not configured exactly the same on both ends of the connection, eventually the connections go stale at one end of the connection, but the other end keeps trying to use them. The symptom is a 502 error.
这听起来像Apache中的mod_jk与JBoss中的AJP连接器不同步。 AJP协议使用Web服务器和应用服务器之间的持久,重用连接,如果协议的两端配置不完全相同,最终连接在连接的一端变得陈旧,但另一端一直试图使用它们。症状是502错误。
My first suggestion is this: don't use mod_jk unless you need to. It's complex and hard to configure to get a stable system. If you don't need its performance or load balancing features, I suggest using mod_proxy instead. It's just as good for most applications, and pretty easy.
我的第一个建议是:除非你需要,否则不要使用mod_jk。它很复杂,很难配置以获得稳定的系统。如果您不需要其性能或负载平衡功能,我建议使用mod_proxy。它对大多数应用程序来说都很好,非常简单。
But if you want to stick to mod_jk, The first thing you need to is make sure you're using the very latest mod_jk version (currently 1.2.28), since older versions are notoriously hard to configure. Luckily, mod_jk is still supported on Apache 1.3.
但是如果你想坚持使用mod_jk,首先要确保你使用最新的mod_jk版本(目前为1.2.28),因为旧版本的配置非常难。幸运的是,Apache 1.3仍然支持mod_jk。
Next, check the mod_jk log file (configured using the JkLogFile directive). If you're seeing a bunch of connection-related errors around the time things go wrong, you need to tweak your jk config at both ends of the connection. The most likely culprit is the timeout settings, so read up about those here, and make sure both ends are singing from the same hymn sheet.
接下来,检查mod_jk日志文件(使用JkLogFile指令配置)。如果您在出现问题时看到一堆与连接相关的错误,则需要在连接的两端调整jk配置。最可能的罪魁祸首是超时设置,所以请阅读这里的内容,并确保两端都是用同一张赞美诗唱歌。
#2
I've also seen this occur using apache and tomcat. In my particular situation, the application deployed to tomcat had a bug that caused response threads to hang. Eventually tomcat ran out of worker threads, and apache wasn't able to establish a connection.
我也看到过这种情况发生在使用apache和tomcat。在我的特定情况下,部署到tomcat的应用程序有一个导致响应线程挂起的错误。最终tomcat耗尽了工作线程,而apache无法建立连接。
In our case, database connections weren't getting released properly back into a connection pool, and other threads were waiting indefinitely to obtain a connection from the pool. However, anything that indefinitely keeps alive a response handling thread could lead to the same problem.
在我们的示例中,数据库连接未正确释放回连接池,并且其他线程无限期地等待从池中获取连接。但是,任何无限期保持响应处理线程的东西都可能导致同样的问题。
#3
I had the same issue but with Apache and Glassfish. Finally, I could fix it configuring the same timeout in both sides.
我有同样的问题,但Apache和Glassfish。最后,我可以修复它在双方配置相同的超时。
In Glassfish changing the listener configuration and in Apache modifiying the worker.properties with this line:
在Glassfish中更改侦听器配置,并在Apache中使用此行修改worker.properties:
worker.worker_name.socket_timeout=300
I am not sure about the way to configure this in JBoss, may be modifying the web.xml or cluster-service.xml.
我不确定在JBoss中配置它的方法,可能是修改web.xml或cluster-service.xml。
#4
If you are connecting Apache with Tomcat and ended up in this blog just like me, it makes sense.
如果您正在将Apache与Tomcat连接起来并且像我一样在这个博客中结束,那么这是有道理的。
Accepting connection for AJP/1.3 in tomcat solved this error for me. Do not forget to comment out the service on HTTP protocol.
在tomcat中接受AJP / 1.3的连接为我解决了这个错误。不要忘记在HTTP协议上注释掉服务。
**<!--<Connector port="8081" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
-->
<Connector port="8081" protocol="AJP/1.3"
connectionTimeout="20000"
redirectPort="8443" />**
#1
This sounds to me like mod_jk in Apache is getting out of sync with the AJP connector in JBoss. The AJP protocol uses persistent, re-used connections between web server and app server, and if the protocol is not configured exactly the same on both ends of the connection, eventually the connections go stale at one end of the connection, but the other end keeps trying to use them. The symptom is a 502 error.
这听起来像Apache中的mod_jk与JBoss中的AJP连接器不同步。 AJP协议使用Web服务器和应用服务器之间的持久,重用连接,如果协议的两端配置不完全相同,最终连接在连接的一端变得陈旧,但另一端一直试图使用它们。症状是502错误。
My first suggestion is this: don't use mod_jk unless you need to. It's complex and hard to configure to get a stable system. If you don't need its performance or load balancing features, I suggest using mod_proxy instead. It's just as good for most applications, and pretty easy.
我的第一个建议是:除非你需要,否则不要使用mod_jk。它很复杂,很难配置以获得稳定的系统。如果您不需要其性能或负载平衡功能,我建议使用mod_proxy。它对大多数应用程序来说都很好,非常简单。
But if you want to stick to mod_jk, The first thing you need to is make sure you're using the very latest mod_jk version (currently 1.2.28), since older versions are notoriously hard to configure. Luckily, mod_jk is still supported on Apache 1.3.
但是如果你想坚持使用mod_jk,首先要确保你使用最新的mod_jk版本(目前为1.2.28),因为旧版本的配置非常难。幸运的是,Apache 1.3仍然支持mod_jk。
Next, check the mod_jk log file (configured using the JkLogFile directive). If you're seeing a bunch of connection-related errors around the time things go wrong, you need to tweak your jk config at both ends of the connection. The most likely culprit is the timeout settings, so read up about those here, and make sure both ends are singing from the same hymn sheet.
接下来,检查mod_jk日志文件(使用JkLogFile指令配置)。如果您在出现问题时看到一堆与连接相关的错误,则需要在连接的两端调整jk配置。最可能的罪魁祸首是超时设置,所以请阅读这里的内容,并确保两端都是用同一张赞美诗唱歌。
#2
I've also seen this occur using apache and tomcat. In my particular situation, the application deployed to tomcat had a bug that caused response threads to hang. Eventually tomcat ran out of worker threads, and apache wasn't able to establish a connection.
我也看到过这种情况发生在使用apache和tomcat。在我的特定情况下,部署到tomcat的应用程序有一个导致响应线程挂起的错误。最终tomcat耗尽了工作线程,而apache无法建立连接。
In our case, database connections weren't getting released properly back into a connection pool, and other threads were waiting indefinitely to obtain a connection from the pool. However, anything that indefinitely keeps alive a response handling thread could lead to the same problem.
在我们的示例中,数据库连接未正确释放回连接池,并且其他线程无限期地等待从池中获取连接。但是,任何无限期保持响应处理线程的东西都可能导致同样的问题。
#3
I had the same issue but with Apache and Glassfish. Finally, I could fix it configuring the same timeout in both sides.
我有同样的问题,但Apache和Glassfish。最后,我可以修复它在双方配置相同的超时。
In Glassfish changing the listener configuration and in Apache modifiying the worker.properties with this line:
在Glassfish中更改侦听器配置,并在Apache中使用此行修改worker.properties:
worker.worker_name.socket_timeout=300
I am not sure about the way to configure this in JBoss, may be modifying the web.xml or cluster-service.xml.
我不确定在JBoss中配置它的方法,可能是修改web.xml或cluster-service.xml。
#4
If you are connecting Apache with Tomcat and ended up in this blog just like me, it makes sense.
如果您正在将Apache与Tomcat连接起来并且像我一样在这个博客中结束,那么这是有道理的。
Accepting connection for AJP/1.3 in tomcat solved this error for me. Do not forget to comment out the service on HTTP protocol.
在tomcat中接受AJP / 1.3的连接为我解决了这个错误。不要忘记在HTTP协议上注释掉服务。
**<!--<Connector port="8081" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
-->
<Connector port="8081" protocol="AJP/1.3"
connectionTimeout="20000"
redirectPort="8443" />**