Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4AA035A1.4080000@christopherschultz.net>
Date: Thu, 03 Sep 2009 17:31:13 -0400
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
 rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: mod jk - multiple applications, different server clusers, sticky
 sessions
References: <534bd38b0909021438p17e13e22m42c2e4432821329b@mail.gmail.com>
 <4A9F8007.4040007@kippdata.de>
In-Reply-To: <4A9F8007.4040007@kippdata.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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