You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Mike Wilson <mi...@hotmail.com> on 2012/04/28 16:52:06 UTC

multiple mod_jk server mappings and JSESSIONID

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?

Best regards
Mike Wilson


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


RE: multiple mod_jk server mappings and JSESSIONID

Posted by Mike Wilson <mi...@hotmail.com>.
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


Re: multiple mod_jk server mappings and JSESSIONID

Posted by Rainer Jung <ra...@kippdata.de>.
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


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


Re: multiple mod_jk server mappings and JSESSIONID

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike,

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?

> 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).

> 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.)

> 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?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+eqS8ACgkQ9CaO5/Lv0PCYpwCeI+BSXcLhZj11prRQdRSODzMB
XDMAniFPBmAnx13PMzzoomaQfcighWmW
=wX91
-----END PGP SIGNATURE-----

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


Re: multiple mod_jk server mappings and JSESSIONID

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Esmond,

On 4/30/12 8:06 AM, Esmond Pitt wrote:
>> I am not sure that mod_jk mappings follow the principle of
>> "longest match
> wins".
> 
> They follow a logic of their own whereby wildcard matches outrank 
> non-wildcard matches, so for example:
> 
> JkMount /* JkUnmount /
> 
> doesn't operate to unmount the Tomcat root, not because it is
> shorter but because it isn't a wildcard (see mod_jk.log).
> 
> The best advice I can give you about mod_jk is not to use it: ditch
> it and use mod_proxy_ajp instead. Much better, much simpler, and no
> messing about between the Tomcat and Apache configurations.

Just because you find mod_proxy_ajp easier to configure doesn't make
it a good recommendation. The OP isn't having any problem that complex
configuration is making any easier or worse.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+ep50ACgkQ9CaO5/Lv0PAuBQCgpYGHiYIrGuHIjyy+BVVK39oF
SCoAoJ+eFRdlfkyTQE1qiftI4d/F52oY
=6dgK
-----END PGP SIGNATURE-----

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


RE: multiple mod_jk server mappings and JSESSIONID

Posted by Esmond Pitt <es...@bigpond.com>.
> I am not sure that mod_jk mappings follow the principle of "longest match
wins".

They follow a logic of their own whereby wildcard matches outrank
non-wildcard matches, so for example:

JkMount /* 
JkUnmount /

doesn't operate to unmount the Tomcat root, not because it is shorter but
because it isn't a wildcard (see mod_jk.log).

The best advice I can give you about mod_jk is not to use it: ditch it and
use mod_proxy_ajp instead. Much better, much simpler, and no messing about
between the Tomcat and Apache configurations.

EJP



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


Re: multiple mod_jk server mappings and JSESSIONID

Posted by André Warnier <aw...@ice-sa.com>.
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".

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