Apache httpd 每次都会创建新的会话（2.2.16 和 2.4.6）

Question 1

实际上，您所描述的情况看起来很难发生。从传入的 cookie/param 解析路由，这似乎相当简单，然后在平衡成员中查找路由。只有这样，如果找不到路由，它才会进入更复杂的基于负载的成员选择。因此，可能是成员出现故障导致查找失败，或者 httpd 失去了对平衡成员的了解。这确实涉及 httpd 线程之间的共享数据，因此这始终是导致麻烦的可能原因。

也许可以尝试标准2.2.26发布，公平地说，没有很多平衡器或者代理代码有自 2.2.16 起发生改变。Debian 确实有一些部分被移植回来了，主要是安全方面，所以那里可能发生了一些奇怪的事情。

看看在问题发生时是否可以正常重启httpd。LogLevel debug如果错误状态仍然存在，您将在错误日志中获得大量有关平衡器成员选择的详细信息，这应该可以让您更好地了解底层正在发生的事情。

如果日志记录失败，请尝试将平衡器环境变量添加到LogFormat定义中，以便将它们放入您的中access.log。您也许能够更好地跟踪它们正在发生的事情：

\"%{BALANCER_NAME}e\"
\"%{BALANCER_WORKER_NAME}e\"
\"%{BALANCER_WORKER_ROUTE}e\"
\"%{BALANCER_SESSION_STICKY}e\"
\"%{BALANCER_SESSION_ROUTE}e\"
\"%{BALANCER_ROUTE_CHANGED}e\"

Answer

实际上，您所描述的情况看起来很难发生。从传入的 cookie/param 解析路由，这似乎相当简单，然后在平衡成员中查找路由。只有这样，如果找不到路由，它才会进入更复杂的基于负载的成员选择。因此，可能是成员出现故障导致查找失败，或者 httpd 失去了对平衡成员的了解。这确实涉及 httpd 线程之间的共享数据，因此这始终是导致麻烦的可能原因。

也许可以尝试标准2.2.26发布，公平地说，没有很多平衡器或者代理代码有自 2.2.16 起发生改变。Debian 确实有一些部分被移植回来了，主要是安全方面，所以那里可能发生了一些奇怪的事情。

看看在问题发生时是否可以正常重启httpd。LogLevel debug如果错误状态仍然存在，您将在错误日志中获得大量有关平衡器成员选择的详细信息，这应该可以让您更好地了解底层正在发生的事情。

如果日志记录失败，请尝试将平衡器环境变量添加到LogFormat定义中，以便将它们放入您的中access.log。您也许能够更好地跟踪它们正在发生的事情：

\"%{BALANCER_NAME}e\"
\"%{BALANCER_WORKER_NAME}e\"
\"%{BALANCER_WORKER_ROUTE}e\"
\"%{BALANCER_SESSION_STICKY}e\"
\"%{BALANCER_SESSION_ROUTE}e\"
\"%{BALANCER_ROUTE_CHANGED}e\"

Question 2

根据您的评论，实际问题是 stickysession 有时对客户端不起作用。

它的工作原理如下：

[client IP:56456] AH01160: Found value 4A0775A9DDFBFB1FE2B6AE14F62C5904.tomcat2 for stickysession JSESSIONID, referer: https://www.x.com/vefsms/
[client IP:56456] AH01161: Found route tomcat2, referer: https://www.x.com/vefsms/
[client IP:56456] AH01172: balancer://ssl-cluster: worker (ajp://tomcat2.x.com:9108) rewritten to ajp://tomcat2.x.com:9108/vefsms-portlets/dwr/interface/Controller.js, referer: https://www.x.com/vefsms/

这里不起作用（注意：不Found route）

[client IP:56456] AH01160: Found value (J2EE4847100)ID1435349250DBfa8033a3ce4db1f64ba8d682cf8c5736533dc780End for stickysession JSESSIONID, referer: http://www.x.com/
<------ no Found route here, so balancing decision happens instead ----->
[client IP:56456] AH01172: balancer://ssl-cluster: worker (ajp://tomcat1.x.com:9108) rewritten to ajp://tomcat1.x.com:9108/vefsms/, referer: http://www.x.com/

显然，原因在于冲突的 cookie (J2EE4847100)ID1435349250DBfa8033a3ce4db1f64ba8d682cf8c5736533dc780End，该 cookie 很可能是在应用程序服务器端插入的。

Answer

根据您的评论，实际问题是 stickysession 有时对客户端不起作用。

它的工作原理如下：

[client IP:56456] AH01160: Found value 4A0775A9DDFBFB1FE2B6AE14F62C5904.tomcat2 for stickysession JSESSIONID, referer: https://www.x.com/vefsms/
[client IP:56456] AH01161: Found route tomcat2, referer: https://www.x.com/vefsms/
[client IP:56456] AH01172: balancer://ssl-cluster: worker (ajp://tomcat2.x.com:9108) rewritten to ajp://tomcat2.x.com:9108/vefsms-portlets/dwr/interface/Controller.js, referer: https://www.x.com/vefsms/

这里不起作用（注意：不Found route）

[client IP:56456] AH01160: Found value (J2EE4847100)ID1435349250DBfa8033a3ce4db1f64ba8d682cf8c5736533dc780End for stickysession JSESSIONID, referer: http://www.x.com/
<------ no Found route here, so balancing decision happens instead ----->
[client IP:56456] AH01172: balancer://ssl-cluster: worker (ajp://tomcat1.x.com:9108) rewritten to ajp://tomcat1.x.com:9108/vefsms/, referer: http://www.x.com/

显然，原因在于冲突的 cookie (J2EE4847100)ID1435349250DBfa8033a3ce4db1f64ba8d682cf8c5736533dc780End，该 cookie 很可能是在应用程序服务器端插入的。

Apache httpd 每次都会创建新的会话（2.2.16 和 2.4.6）

答案1

答案2

相关内容