tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: mod_jk and session stickiness
Date Tue, 08 Jul 2014 12:29:57 GMT
Hash: SHA256


On 6/17/14, 10:43 AM, Christopher Schultz wrote:
> All,
> I've been using sticky sessions with mod_jk and I can see that
> there is a bit of a problem when attempting to take a backend
> Tomcat server out of load-balanced rotation: a user who never (or
> rarely) restarts their web browser will keep the same JSESSIONID
> cookie forever and therefore end up with the same backend server
> whether it has been disabled or not.
> Quick series of events:
> 1. User visits load-balancer and gets a randomly-assigned backend 
> server/route. We'll call this route "X". The JSESSIONID cookie set
> by the backend server is therefore foo.X.
> 2. User's requests are routed by mod_jk to route X.
> 3. Route X is disabled using mod_jk's status worker
> 4. User's session on server X expires.
> [Technically, 3 and 4 can happen in either order]
> 5. User makes a new request to the load-balancer, and mod_jk sees
> the JSESSIONID cookie still set to foo.X. mod_jk sends the request
> to route X which allows the user to login, etc.
> Thus, it takes more time than necessary to bleed all the traffic
> from route X for maintenance, etc.
> Is there a way for mod_jk to ask route X if the session is *still* 
> valid? It seems that mod_jk will not re-route a request that looks 
> like it's got a valid session id to a new (active) backend server 
> unless the backend server X is actually down.
> Any ideas?

Any takers?

I was thinking that the following strategy might work:

1. Extend mod_jk's load-balancer worker to include a new directive:
rebalance_statuses, then set the value for that directive to some very
rare HTTP status code(s) like 502.

2. Add a Valve/Filter/Whatever to Tomcat that, when activated because
you want to take a node out of service) returns a 502 when a session
identifier is used that does not map to a currently-valid session and
there is no "force-new-session" header included in the request with
some unpredictable value to prevent end-users from sending their own
valid headers. This could also be handled by the same component
(Manager) that current creates sessions with a new configuration option.

These two together would then bleed-off the aforementioned users: in
step 5, the request would be routed to Tomcat X, then rejected with a
502. mod_jk would detect this and re-balance the worker. If mod_jk
can't re-balance the worker to another backend (e.g. they are all
disabled, stopped, or in a failure state), then mod_jk would send the
request (back) to Tomcat X with the force-new-session header set.

Other than the above (or something similar), or actively probing a
backend Tomcat to see if a session is valid, does anyone have any
ideas for how to get a backend Tomcat into a completely idle state
before pulling the plug?

- -chris
Version: GnuPG v1
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message