You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Rainer Jung <ra...@kippdata.de> on 2009/09/03 10:36:23 UTC
Re: mod jk - multiple applications, different server clusers, sticky
sessions
On 02.09.2009 23:38, Jason Wright wrote:
> I've an interesting situation with our application clusters. I am running
> multiple applications for one of our websites. We don't share sessions
> between the different servers; we use sticky sessions instead. Session
> replication is difficult because of the large size of our users' sessions.
>
> We use applications A & B. I would like application A to run on servers 1
> and 2 and application B to run on servers 3 and 4.
>
> The user initially requests application A and receives a sticky session for
> server 1. Later, the user requests application B. Since the sticky session
> was set, server 1 is accessed, but application B is not found. If
No.
The stickyness doesn't magically track your clients. If the client sends
a session information, and the session information contains a route tag
(a suffix .nodeX, where nodeX is set by the jvmRoute attribute in
server.xml), then mod_jk looks for a balancer member named nodeX.
When/How does the client send session information? Either as a cookie
named JSESSIONID, or via URL encoding ...;jsessionid=....nodeX
By default, application A with context name /myappA uses cookies and
only sends cookies if the request goes to something in /myappA. So a
request for application B with context /myappB doesn't include the
cookie for A and the load balancer is free to distribute the request to
any node.
> sticky_session_force is set, then another server is tried; however, the
No, see above. No session info, then stickyness is never applied.
If there were session info, then the force switch would work in the
opposite way, namely if set to false, it will allow failover. Default is
false.
> sticky session will still be set to server 1 and the application B may not
> use the same server.
>
> I've thought of 3 possible ways to solve this problem with a preference to
> the one I don't know how to do yet.
Not sure what the (real) problem is, likely you want both apps to be
reachable under the same server name.
> The first (my preference) is to be able to use multiple sticky sessions, one
> for each application. This might involve multiple copies of modjk loaded by
> tomcat with multiple workers.properties files, or something like that. I
> would have no idea of how to do this. Does anyone know how to do this?
No, this works out of the box. I assume there is no relation between the
two apps A and B.
Configute two lb workers, like lbA and lbB. One has member node1 and
node 2, the other node3 and node4. Set the jvmRoute in server.xml of the
four nodes to these names respectively. Finally add a
JkMount /myappA|/* lbA
JkMount /myappB|/* lbB
That should be all that's needed.
When testing, check the session cookies in order to understand what's
going on. There are lots of Firefox plugins to look at cookies
comfortably, like e.g. FireCookie. FireBug is also nice.
> The second way of solving this problem is to use multiple copies of Tomcat
> bound to different IP addresses with different configuration files. This
> solution would be seen as subdomains to the user.
>
> The third way of solving this problem is to use multiple copies of Tomcat
> bound to different ports (same IP address) with different configuration
> files. This solution would have the same domain, but different port numbers.
>
>
> I'm pretty sure that the second and third solutions would work, but I'm not
> sure about the first solution. I've searched extensively and haven't found
> anyone with the same problem. Has anyone on this list been in this situation
> or know the best way to solve this problem?
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod jk - multiple applications, different server clusers, sticky
sessions
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rainer,
On 9/7/2009 6:05 AM, Rainer Jung wrote:
> The code of mod_jk (1.2.28) looks for a URL encoded session id (and uses
> that one if it finds one) and otherwise it takes all cookie session ids
> it can find in the order of Cookie headers in the request.
>
> It then uses all the session ids in this order and searches for a usable
> worker (e.g. existing and not being in error or stopped) until it finds
> one or runs out of session ids.
Okay, so if you were foolish enough to have nested webapp paths, then
you'd be okay as long as the worker names didn't conflict, right?
That might mean you'd need different <Connector>s in order to satisfy
your nested-url-space requirement, but at least the behavior would be
predictable.
Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkqpMzoACgkQ9CaO5/Lv0PBGRwCgtuOqeUYtM5v6k0JTbcw55pY9
Wq0AnjhRVt9s4Easg+e42a9TL66uFGYC
=Z8eI
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod jk - multiple applications, different server clusers, sticky
sessions
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Chris,
On 04.09.2009 16:29, Christopher Schultz wrote:
> Rainer,
>
> On 9/4/2009 12:52 AM, Rainer Jung wrote:
>> On 03.09.2009 23:31, Christopher Schultz wrote:
>>> Whenever a client browses to webapps found on / and /foo, the requests
>>> to /foo will get TWO cookies, and confusion may occur (I'm not sure what
>>> mod_jk will do in this situation... Rainer?).
>
>> Not sure either :(
>
>> Even if I looked at the code now, I wouldn't take it for granted, that
>> the behaviour can't change.
>
> Agreed. I don't have a cluster handy to test, but it would be good to
> know what mod_jk actually does in the case where multiple JSESSIONID
> cookies exist and have different jvmRoute suffixes.
>
>> Actually I'm not even sure what the browser is supposed to send (the
>> same cookie multiple times, or only the one with the longest path
>> match).
>
> My experience was that /both/ cookies were sent (which makes sense,
> since there's no prohibition against the same cookie name being used
> more than one time when a different path is used).
OK, I did some (very little) work:
RFC 2109 and 2965 both state:
If multiple cookies satisfy the criteria above, they are ordered in
the Cookie header such that those with more specific Path attributes
precede those with less specific. Ordering with respect to other
attributes (e.g., Domain) is unspecified.
(sections 4.3.4 resp. 3.3.4).
The code of mod_jk (1.2.28) looks for a URL encoded session id (and uses
that one if it finds one) and otherwise it takes all cookie session ids
it can find in the order of Cookie headers in the request.
It then uses all the session ids in this order and searches for a usable
worker (e.g. existing and not being in error or stopped) until it finds
one or runs out of session ids.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod jk - multiple applications, different server clusers, sticky
sessions
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rainer,
On 9/4/2009 12:52 AM, Rainer Jung wrote:
> On 03.09.2009 23:31, Christopher Schultz wrote:
>> Whenever a client browses to webapps found on / and /foo, the requests
>> to /foo will get TWO cookies, and confusion may occur (I'm not sure what
>> mod_jk will do in this situation... Rainer?).
>
> Not sure either :(
>
> Even if I looked at the code now, I wouldn't take it for granted, that
> the behaviour can't change.
Agreed. I don't have a cluster handy to test, but it would be good to
know what mod_jk actually does in the case where multiple JSESSIONID
cookies exist and have different jvmRoute suffixes.
> Actually I'm not even sure what the browser is supposed to send (the
> same cookie multiple times, or only the one with the longest path
> match).
My experience was that /both/ cookies were sent (which makes sense,
since there's no prohibition against the same cookie name being used
more than one time when a different path is used).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkqhJEcACgkQ9CaO5/Lv0PDpggCgv1aVrfTiq9MH1SF2Td4Ha3EP
iY0AoLnXxKeQ6iKeermF2JbvCRjEGoaQ
=I2jx
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod jk - multiple applications, different server clusers, sticky
sessions
Posted by Rainer Jung <ra...@kippdata.de>.
On 03.09.2009 23:31, Christopher Schultz wrote:
> Rainer,
>
> On 9/3/2009 4:36 AM, Rainer Jung wrote:
>> No.
>
>> The stickyness doesn't magically track your clients. If the client sends
>> a session information, and the session information contains a route tag
>> (a suffix .nodeX, where nodeX is set by the jvmRoute attribute in
>> server.xml), then mod_jk looks for a balancer member named nodeX.
>
>> When/How does the client send session information? Either as a cookie
>> named JSESSIONID, or via URL encoding ...;jsessionid=....nodeX
>
>> By default, application A with context name /myappA uses cookies and
>> only sends cookies if the request goes to something in /myappA. So a
>> request for application B with context /myappB doesn't include the
>> cookie for A and the load balancer is free to distribute the request to
>> any node.
>
> One caveat: if you have a ROOT context along with other non-ROOT
> contexts, things can get tricky because you'll get cookies like:
>
> name=JSESSIONID, path=/, expires=..., value=...
> name=JSESSIONID, path=/foo, expires=..., value=...
> name=JSESSIONID, path=/bar, expires=..., value=...
>
> Whenever a client browses to webapps found on / and /foo, the requests
> to /foo will get TWO cookies, and confusion may occur (I'm not sure what
> mod_jk will do in this situation... Rainer?).
Not sure either :(
Even if I looked at the code now, I wouldn't take it for granted, that
the behaviour can't change. Actually I'm not even sure what the browser
is supposed to send (the same cookie multiple times, or only the one
with the longest path match).
> My advice is to avoid "nesting" webapp URL spaces. I accidentally did
> this for years until I discovered the problem when adding
> sessionid-passthrough to another webapp (where the session id couldn't
> be validated before being passed-through) and everything went crazy.
> When I separated the URL spaces, everything was fine.
>
> Hope that helps,
> -chris
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod jk - multiple applications, different server clusers, sticky
sessions
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rainer,
On 9/3/2009 4:36 AM, Rainer Jung wrote:
> No.
>
> The stickyness doesn't magically track your clients. If the client sends
> a session information, and the session information contains a route tag
> (a suffix .nodeX, where nodeX is set by the jvmRoute attribute in
> server.xml), then mod_jk looks for a balancer member named nodeX.
>
> When/How does the client send session information? Either as a cookie
> named JSESSIONID, or via URL encoding ...;jsessionid=....nodeX
>
> By default, application A with context name /myappA uses cookies and
> only sends cookies if the request goes to something in /myappA. So a
> request for application B with context /myappB doesn't include the
> cookie for A and the load balancer is free to distribute the request to
> any node.
One caveat: if you have a ROOT context along with other non-ROOT
contexts, things can get tricky because you'll get cookies like:
name=JSESSIONID, path=/, expires=..., value=...
name=JSESSIONID, path=/foo, expires=..., value=...
name=JSESSIONID, path=/bar, expires=..., value=...
Whenever a client browses to webapps found on / and /foo, the requests
to /foo will get TWO cookies, and confusion may occur (I'm not sure what
mod_jk will do in this situation... Rainer?).
My advice is to avoid "nesting" webapp URL spaces. I accidentally did
this for years until I discovered the problem when adding
sessionid-passthrough to another webapp (where the session id couldn't
be validated before being passed-through) and everything went crazy.
When I separated the URL spaces, everything was fine.
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkqgNaEACgkQ9CaO5/Lv0PC7nQCgtvFONQbvlmx7zrz+rmKaFVdI
PcgAnjDcnYoWXNmsMW8bIE58tSnUBFuG
=9T+N
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org