Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon,
Simon Papillon wrote:
| when there are
| several all servicing requests in a load balanced context, it doesn't
| work, because the session ids from different domains may be directed
| to different tomcat instances
Simon Papillon wrote:
Forgive me if I'm overlooking something, but as far as I understand
it, the sticky session mechanism is driven off the JSESSIONID that is
assigned by the tomcat container when a client first makes a request
that instigates a session creation, if no JSESSIONID cookie was
On Fri, 2008-06-13 at 10:54 +0200, Rainer Jung wrote:
Environment variable in httpd can be set by mod_setenvif and
mod_rewrite, which are both able to check various request properties.
For instance mod_rewrite can check the Cookie header, so you could
extract the name of the chosen
Ben Stringer wrote:
On Fri, 2008-06-13 at 10:54 +0200, Rainer Jung wrote:
Environment variable in httpd can be set by mod_setenvif and
mod_rewrite, which are both able to check various request properties.
For instance mod_rewrite can check the Cookie header, so you could
extract the name of
Hi Chris,
So just to follow up on your post,
So, really, it's not that you want to load balance based upon IP
address... you really want to predictably choose a member of the server
farm based upon some knowledge of the client such that, regardless of
the domain name used, the initial request
Ben, Rainer,
That is an excellent idea, and would seem to be a very elegant
solution, I'll give it a shot.
Thank you both very much. I really appreciate it.
Cheers
Simon
-
To start a new topic, e-mail: users@tomcat.apache.org
- Original Message -
From: Simon Papillon [EMAIL PROTECTED]
To: users@tomcat.apache.org
Sent: Thursday, June 12, 2008 7:11 PM
Subject: jk load balancing based upon ip address rather than session id
Hello,
I'm using jk 1.2.25 with tomcat 5.5.25 and apache 2.0 on one debian
box
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon,
Simon Papillon wrote:
| I'll check this out, I think you could be right, it will probably lead
| to a lumpy load profile accross the tomcat servers, but I might give
| it a go.
Yeah, but a lumpy load profile that works properly is better
Hi.
Sorry to butt in, but just by curiosity from a Tomcat rookie, do you
absolutely need to keep handling the same client IP with the same Tomcat
instance ?
(Do not feel obliged to comment at length, if it would not work, just
tell me so and I'll get back to my Apache/Tomcat studies.)
My
From: André Warnier [mailto:[EMAIL PROTECTED]
Subject: Re: jk load balancing based upon ip address rather
than session id
Then at the Tomcat level (whichever instance), you could retrieve this
cookie and the identifier it contains, and use that as a key to some
user session storage
Hi André,
You could do the authentication and SSO handling at the Apache level, and
set some partial domain cookie at that level, with some cross-domain
identifier (as long as the domains have a common part of course).
The browser will later send this cookie back with each request addressed
Hi Chris,
Wow, does that really work? That's a tremendously cool hack, if so!
It seems to, although it's not yet been tested in anger and there is
scope for dependancy issues if you navigate from one domain directly
to the another expecting a continous session experience.
What I mean is that
Simon Papillon wrote:
as long as the domains have a common part of course
Unfortunately in my case that doesn't hold true, its an international
site, and we've got the same domain names for different tlds e.g.:
mydomain.com
mydomain.com.ar
I am not really a specialist of Tomcat, so I'll stick
Hello,
I'm using jk 1.2.25 with tomcat 5.5.25 and apache 2.0 on one debian
box - 2.4.27-2-386 i686 GNU/Linux
I've set up 3 tomcat instances that receive requests from the jk
load balancer worker
I've implemented in the web application, a simple cross domain single
sign on (SSO) mechanism.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon,
Simon Papillon wrote:
| when there are
| several all servicing requests in a load balanced context, it doesn't
| work, because the session ids from different domains may be directed
| to different tomcat instances / containers, which then
Hi Chris,
Thanks for the reply,
Simon,
Simon Papillon wrote:
| when there are
| several all servicing requests in a load balanced context, it doesn't
| work, because the session ids from different domains may be directed
| to different tomcat instances / containers, which then breaks the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon,
Simon Papillon wrote:
| Forgive me if I'm overlooking something, but as far as I understand
| it, the sticky session mechanism is driven off the JSESSIONID that is
| assigned by the tomcat container when a client first makes a request
| that
17 matches
Mail list logo
