Return-Path: 
 <users-return-108802-apmail-httpd-users-archive=httpd.apache.org@httpd.apache.org>
X-Original-To: apmail-httpd-users-archive@www.apache.org
Delivered-To: apmail-httpd-users-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 5B3F911646
	for <apmail-httpd-users-archive@www.apache.org>;
 Thu, 27 Mar 2014 10:05:59 +0000 (UTC)
Received: (qmail 42327 invoked by uid 500); 27 Mar 2014 10:05:56 -0000
Delivered-To: apmail-httpd-users-archive@httpd.apache.org
Received: (qmail 41682 invoked by uid 500); 27 Mar 2014 10:05:52 -0000
Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
list-help: <mailto:users-help@httpd.apache.org>
list-unsubscribe: <mailto:users-unsubscribe@httpd.apache.org>
List-Post: <mailto:users@httpd.apache.org>
List-Id: <users.httpd.apache.org>
Delivered-To: mailing list users@httpd.apache.org
Received: (qmail 41599 invoked by uid 99); 27 Mar 2014 10:05:49 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Mar 2014 10:05:49 +0000
X-ASF-Spam-Status: No, hits=1.0 required=5.0
	tests=SPF_SOFTFAIL
X-Spam-Check-By: apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 royster.lim@gmail.com does not designate 216.139.250.139 as permitted sender)
Received: from [216.139.250.139] (HELO joe.nabble.com) (216.139.250.139)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Mar 2014 10:05:45 +0000
Received: from alf.nabble.com ([192.168.236.21])
	by joe.nabble.com with esmtp (Exim 4.72)
	(envelope-from <royster.lim@gmail.com>)
	id 1WT7BD-0003c4-Tu
	for users@httpd.apache.org; Thu, 27 Mar 2014 03:05:00 -0700
Date: Thu, 27 Mar 2014 03:04:44 -0700 (PDT)
From: royster <royster.lim@gmail.com>
To: users@httpd.apache.org
Message-ID: <1395914684763-5013169.post@n6.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
Subject: [users@httpd] Session stickiness stops working for no reason

We're running Apache 2.4.7, fronting Tomcat app servers.

We are noticing that often mod_proxy_balancer completely ignores the tomcat
route id and hands the inbound http request to the other node.  Hence, new
JSESSIONID is assigned and user loses their session.

Here's the relevant apache configs (both nodes have same config):

<Proxy balancer://mybalancer>
  BalancerMember ajp://A2.xxx.net:8009 route=route1 keepalive=On ping=3
  BalancerMember ajp://A3.xxx.net:8009 route=route2 keepalive=On ping=3
  ProxySet stickysession=JSESSIONID|jsessionid lbmethod=byrequests
timeout=20
</Proxy>

And tomcat configs:

<Engine name="Catalina" defaultHost="localhost" jvmRoute="route1">
<Engine name="Catalina" defaultHost="localhost" jvmRoute="route2">

I enabled debug for proxy_balancer and here's what I see:

mod_proxy_balancer.c(668): [client 10.28.72.2:24007] AH01176:
proxy_balancer_post_request for (balancer://mybalancer)
mod_proxy_balancer.c(292): [client 10.28.72.2:21164] AH01160: Found value
E8F368E83EF92643FAD57F210628437C.route1 for stickysession JSESSIONID
mod_proxy_balancer.c(303): [client 10.28.72.2:21164] AH01161: Found route
route1
mod_proxy_balancer.c(615): [client 10.28.72.2:21164] AH01172:
balancer://mybalancer: worker (ajp://A3.xxx.net:8009) rewritten to
ajp://A3.xxx.net:8009/

You can see here A3 was selected, despite the fact that route1 is mapped to
A2 and should have been selected instead!  What gives?  There's no error
reported WRT A2 (above is the error log), so what could it be?

A quick fix may be to turn set nofailover=ON, but I really want to
investigate why it's doing this.  It happens frequently, and it may be
correlated to when the tomcat node may be under moderate load, but I'm not
entirely sure.  During these times, I've checked the number of connections
in Tomcat (via netstat) and they're well under the maxThreads setting for
AJP connector.

The docs also state fail over can happen if the targeted worker is in
"error" state.  But I can see it service unrelated requests right after. 
Besides nothing in the log to indicate so...I am really at a loss here.

Any advice on troubleshooting this would be appreciated!



--
View this message in context: http://apache-http-server.18135.x6.nabble.com/Session-stickiness-stops-working-for-no-reason-tp5013169.html
Sent from the Apache HTTP Server - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org