Cookies + clustering + 4.0.3 = ignored context.xml

[coreyjohnston]

While I haven't done a lot of investigation to the exact cause, there appears to be something that's changed between 4.0.2RC1 and 4.0.3SP1 that's causing JBoss to enable cookies in a webapp when running in a cluster ("all" config), despite the app explicitly -disabling- cookies.

I've run the same app on both a default server (non-cluster) and a clustered server, both on 4.0.3SP1, and cookies are disabled correctly in the first instance, but when running as a clustered server.

I'm upgrading from v4.0.2RC1, where JBoss correctly disables cookies (due to the app's context.xml cookies=false directive), and have found this peculiarity.

As mentioned, the problem appears on 4.0.3SP1 only when in clustered mode; if run as a singleton instance ("default" config), it disables cookies as expected.

Any ideas would be greatly appreciated!

[coreyjohnston]

Problem solved.

It's not actually a problem in the new version, 4.0.3, as expected.

The problem actually exists in 4.0.2 too, but its got nothing to do with clustering.

Rather, the problem is to do with cookies.

The problem occurred when I accessed a web app B on our server that explicitly "disables" cookies, after using web app A on the same server that uses cookies.

What happened is that web app B used a cookie instead of URL-rewriting, even though its deploy descriptors explicitly disable cookies.

It seems that the cookie (legitimately) set by A ("jsessionid") is then used by the same browser when application B is later accessed. I don't know why that this is, but it seems to be a fault on the part of the appserver.

ie: If an app explicitly disables cookies, I would expect the apperver to not dish-out or accept cookies for that app. However the jboss-web directive "use-session-cookies" and the context.xml directive "Context cookies="false"" seem to only have the affect of the appserver having a preference for URL rewriting, as opposed to totally disabling cookies.

I'm not sure whether this is a bug with JBoss or Tomcat (I'm inclined to think Tomcat, maybe), or whether this is just a known evil that people seem to have put-up with.

A bit of a pita to work-around, but I'm trying to investigate the possibility of changing the cookie's path from "/" to being, say, the context root of that webapp, so webapp A's cookies are not used in webapp B. NB: I'm talking only of cookies sent by the container (not user cookies), so I'm not sure JBoss/Tomcat provides any facilities to change this.

Potentially also investigating that possibility of changing Tomcat's directive emptySessionPath from true (in JBoss) back to false (to match the Tomcat default).

Of course any suggestions would be welcomed!

[brian.stansberry]

"coreyjohnston" wrote:

A bit of a pita to work-around, but I'm trying to investigate the possibility of changing the cookie's path from "/" to being, say, the context root of that webapp, so webapp A's cookies are not used in webapp B. NB: I'm talking only of cookies sent by the container (not user cookies), so I'm not sure JBoss/Tomcat provides any facilities to change this.

Potentially also investigating that possibility of changing Tomcat's directive emptySessionPath from true (in JBoss) back to false (to match the Tomcat default).

I'm quite certain setting the emptySessionPath switch to false will result in the cookie path being the context root of the webapp.

[coreyjohnston]

>> I'm quite certain setting the emptySessionPath switch to false will result in the cookie path being the context root of the webapp.

Agreed. And I tried this and it works perfectly in that the cookies set by app A will not prevent app B from using URL encoding (cookies disabled)..

BUT...

I'm not sure if JBoss is OK to run with emptySessionPath set to true in clustered mode.. See the Jira post: http://jira.jboss.com/jira/browse/JBAS-1400

This seems to suggest that emptySessionPath should be set to true (ie: intentionally override Tomcat default) for JvmRouteValve (which I believe is used when clustering.. which I am).

So not sure whether its safe to change this default...

[brian.stansberry]

Had a look at the JvmRouteValve code and it has logic to handle either value of emptySessionPath. Just to be sure I configured a cluster server with this set to false and ran the session replication unit tests and they passed. So I don't think that will be a problem.

However, the JvmRouteValve does require the use of cookies, which seems to defeat your whole purpose. Note however that this valve only gets installed if you are using mod_jk for load balancing.

[coreyjohnston]

Thanks you very much for your investigation, and for testing that Brian.

I have also tested it on a clustered pair using Apache2/mod_jk as a frontend load-balancer, with cookies disabled, and all appears to work fine.

I think its because with cookies disables, JBoss reverts to using URL-rewriting, and tacks-on the necessary extra information into the URL (ie. the Engine name of the Tomcat/JBoss instance being used to ensure "sticky" sessions). I couldn't find any documentation to say that cookies need to be used when clustering, so I figured that because it was working correctly with URL-rewriting, that this must also be fine.

[brian.stansberry]

Hmm, interesting. I based my comment about the requirement for cookies on the following bit from the JvmRouteValve's checkJvmRoute() method:

// Check if incoming session id has JvmRoute appended. If not, append it.
 // TODO. We handle only get session id by cookie only
 if (req.isRequestedSessionIdFromURL())
 {
 // Warning but do nothing
 log_.error("JvmRoutValve.checkJvmRoute(): Can't handle clustering where session id is from URL. Will skip.");
 }
 else
 {
 handleJvmRoute(sessionId, jvmRoute, res);
 }

Did you have any ERROR messages in your logs? Besides ERROR messages in the logs, this would only surface as a problem if a session failover occured.

[coreyjohnston]

Ummm. yes.. I've -just- noticed that error message.

(shrugs head in shame... I should have picked that up sooner but I don't recall seeing that error message. Is it new? my only defence is that our logs become huge very quickly)

Functionally, I tested the session failover by starting the session on the one JBoss instance, but then manually forced it to change-over to the second node by changing the URL.

ie: started with the session on node0 (as you can tell from the host and the extra info mod_jk has tacked on the end)

http://node0:8080/testapp/test.do;jsessionid=O+r5weKUYSCt-Q3gORsdzA**.node0

and changed it to

http://node1:8080/testapp/test.do;jsessionid=O+r5weKUYSCt-Q3gORsdzA**.node0

And I could tell from the logs that the session is moved from node0 to node1. ie: the host changed to node1 but the correct session (identified by the jsessionid AND the mod_jk engine name) was able to continue running from node1. Given this, it seemed like functionally the clustering and session replication was working fine.

Also, just as an aside, I would have thought that using mod_jk and Apache as a front-end load-balancer might be quite a common setup for clustering. If this requires cookies to be used, and JBoss can't use URL rewriting in clustered mode, maybe this should be put into the nodes/wikis about clustering? Seems like a fairly significant thing. Or better yet, maybe JBoss should refuse to deploy the app?

thanks again (heaps) for your assistance and feedback!

[brian.stansberry]

"coreyjohnston" wrote:
I could tell from the logs that the session is moved from node0 to node1. ie: the host changed to node1 but the correct session (identified by the jsessionid AND the mod_jk engine name) was able to continue running from node1. Given this, it seemed like functionally the clustering and session replication was working fine.

Good to know, and thank you for reporting this. I need to improve my understanding of exactly what mod_jk does with the jvmRoute appended to the cookie. I'm *guessing* that it's an optimization, and not a requirement. If the jvmRoute points to a defunct server, perhaps mod_jk falls back to looking up the regular session id in a table it keeps. But this is speculation on my part.

"coreyjohnston" wrote:

Also, just as an aside, I would have thought that using mod_jk and Apache as a front-end load-balancer might be quite a common setup for clustering. If this requires cookies to be used, and JBoss can't use URL rewriting in clustered mode, maybe this should be put into the nodes/wikis about clustering? Seems like a fairly significant thing. Or better yet, maybe JBoss should refuse to deploy the app?

Once I get a chance to investigate further, I'll either document the cookie requirement on the wiki (if its valid) or remove the ERROR message if the requirement isn't real.