tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Wilson <mike...@hotmail.com>
Subject RE: multiple mod_jk server mappings and JSESSIONID
Date Sun, 10 Jun 2012 11:30:57 GMT
Hi folks, I've been sidetracked for a while but have everything 
up and running now. We use load balancing so the critical part
of our resulting configuration became this:

workers.properties:
  worker.serverB-lb.type=lb
  worker.serverB-lb.sticky_session=1
  worker.serverB-lb.session_cookie=JSESSIONID2
  worker.serverB-lb.session_path=;jsessionid2
  worker.serverB-lb.balance_workers=serverB-1, serverB-2, serverB-3

serverB-1 server.xml:
  <Engine ... jvmRoute="serverB-1">
[serverB-2 and serverB-3 accordingly]

uriworkermap.properties:
  /* = serverA-lb
  /path2|/* = serverB-lb
  /path3|/* = serverB-lb
  /path3/xyz|/* = serverA-lb

For future reference I answer your replies below. Thanks for all 
input!

Best regards
Mike

Rainer Jung wrote 28 april 2012 17:16:
> On 28.04.2012 16:52, Mike Wilson wrote:
> > I need to set up a configuration where a site's path space
> > gets distributed over two servers and I'm looking at using
> > mod_jk like this:
> >
> >    Apache httpd
> >      mod_jk
> >        workers.properties
> >          workerA ->  serverA
> >          workerB ->  serverB
> >        uriworkermap.properties
> >          /*       = serverA
> >          /path2/* = serverB
> >          /path3/* = serverB
> >          /path3/xyz/* = serverA
> >
> > F ex "/" and "/path1/" would be directed to serverA and
> > "/path2/" would be directed to serverB. This is all fine.
> >
> > But how do I best solve the issue with each server setting
> > its own JSESSIONID? The browser client will see one site
> > with one domain and one JSESSIONID cookie, so this will
> > cause interference between the two servers when switching
> > between pages.
> >
> > Does mod_jk offer any feature to solve this, or is my best
> > bet to change the name of the JSESSIONID cookie on one of
> > the servers?
> 
> No, there's no builtin feature for that in mod_jk. You could try to 
> fiddle around with the Set-Cookie and Cookie headers using 
> mod_headers. 
> I suggest using a backend feature to switch cookie name there.
> 
> Note that the client should also respect the path when choosing the 
> correct cookie in case multiple cookies match the server. I'd 
> hope the 
> longest path wins in case there are multuple matching paths. Did you 
> test, whether there's actually a problem with those cookies?
> 
> Just in case: you can log the cookies in the server access log for 
> debugging purposes by adding %{Set-Cookie}o and %{Cookie}i to your 
> LogFormat in Apache.
> 
> Regards,
> 
> Rainer

Hi Rainer,

Based on your comments I chose a backend feature to switch cookie name.
ServerA and ServerB both believe they are serving the root directory
(contextPath=/) so their cookies both have path=/, so I couldn't use
client-side path resolution for two cookies with same name.

Thanks!



André Warnier wrote 29 april 2012 00:04:
> Mike Wilson wrote:
> > I need to set up a configuration where a site's path space 
> > gets distributed over two servers and I'm looking at using 
> > mod_jk like this:
> > 
> >   Apache httpd
> >     mod_jk
> >       workers.properties
> >         workerA -> serverA
> >         workerB -> serverB
> >       uriworkermap.properties
> >         /*       = serverA
> >         /path2/* = serverB
> >         /path3/* = serverB
> >         /path3/xyz/* = serverA
> > 
> 
> You may have a problem with the above mappings, since
> /* overlaps everything, and /path3/* overlaps /path3/xyz/*.
> I am not sure that mod_jk mappings follow the principle of 
> "longest match wins".

Hi Andre,

Mod_jk has a principle of longest match wins so this is a supported
configuration:
http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html
  "the URI patterns are sorted by the number of '/' characters in 
  the pattern (highest number first), and rules with equal numbers 
  are sorted by their string length (longest first)."



Christopher Schultz wrote 30 april 2012 17:01:
> On 4/28/12 10:52 AM, Mike Wilson wrote:
> > uriworkermap.properties /*       = serverA /path2/* = serverB 
> > /path3/* = serverB /path3/xyz/* = serverA
> 
> Like André, I'm curious about this, too. I would have expected some of
> these things to interfere with each other. Are you just using
> shorthand when you say /path2/* or is that similar to your 
> real JkMount?

As you can see in the config summary at the top this is pretty much
exactly what I declare to mod_jk.

> > But how do I best solve the issue with each server setting its own
> > JSESSIONID?
> 
> The first thing to determine is if you actually have a problem: Tomcat
> can tolerate having multiple JSESSIONID cookies coming-in from a
> request. It will try the JSESSIONID cookies sequentially until it
> finds a valid one. So, there's no reason two webapps cannot share the
> same URL space (though you're in for some surprises, occasionally).

Ok, that's interesting to know. I did some tests on my cluster setup
and was loosing sessions so I went with the cookie name renaming
scheme instead.

> > The browser client will see one site with one domain and one
> > JSESSIONID cookie, so this will cause interference between the two
> > servers when switching between pages.
> 
> Remember that a cookie also has a "path" associated with it. What are
> the webapp context paths for your various webapps? If they are both
> "/" (i.e. the ROOT webapp) then you are kind of screwed: the webapps
> will fight each other for the JSESSIONID cookie and your client will
> probably always send the wrong cookie. :(
> 
> If you have disjoint paths (/foo versus /bar) then everything will be
> fine. If you have nested paths (/ versus /foo -- which is looks like
> you probably do), then things will *mostly* work, except when they
> don't. I had the experience of using nested paths in the past and
> things became very confused under certain circumstances.
> 
> (IIRC, we were also using proxied-JSESSIONIDs through the nested URL
> space to communicate back to the top-level URL space so we couldn't
> have Tomcat tell us if a session id was valid or not... we had to
> blindly choose one of the JSESSIONID cookies and send *that* to the
> Tomcat back-end. I can see that this isn't making any sense and it was
> kind of a cluster#$@*%& so forget it.)

We have contextPath=/ on both server clusters so, yeah, problems :-)

> > Does mod_jk offer any feature to solve this, or is my best bet to
> > change the name of the JSESSIONID cookie on one of the servers?
> 
> I would go back to my first question: is there actually a problem? Or,
> are you simply forecasting one?

Both it seems :-)
Thanks for your input!


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


Mime
View raw message