Re: jk load balancing based upon ip address rather than session id
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 / containers, which then breaks the | assumption that the SSO mechanism relies upon (that all sessions being | held in a single container). | | The tomcat instances aren't in a distributed cluster and I'd like to | keep it that way. Isn't this what sticky sessions are for? You get randomly assigned to a server for your first request, and each subsequent request goes to that same server (unless it goes down, in which case you have to switch). This does not require distributable sessions. Does that not solve your SSO requirement? I would think so too. I don't see any speciality w.r.t. SSO. - you give each backend a different jvmRoute in server.xml - you give the loab balancer member workers the same names as the jvmRoute of the backend they point to - you activate sticky sessions in the load balancer That should be it. Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk load balancing based upon ip address rather than session id
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 sent as part of the request the node is chosen according to the worker.loadbalancer.method (Request, Session, Traffic, Busyness i think Request is the default) . Once a JSESSIONID has been set by a container the load balancer will then attach the JVMRoute onto the end which will then be used by the jk load balancer in future requests to determine the node to use to service the request. e.g. if I have three nodes (tomcatA, tomcatB, tomcatC) I could have the following scenario... child.first-domain.com : JSESSIONID = D75AA77AC6FBF43F2C2DDC195DDA6D44.tomcatC doctor.second-domain.com : JSESSIONID = 5D211C177DFB064DEF731832CF07D693.tomcatA nurse.third-domain.co.uk : JSESSIONID = E1EC672CAAA3F2F8348C2A23991DF46B.tomcatB Where my browser has made three seperate requests for three seperate resources, all serviced by the same group of tomcat containers through vhosting, behind the load balancer, in which case my SSO mechanism won't work as future requests on child.first-domain.com, doctor.second-domain.com and nurse.third-domain.co.uk will behandled by tomcatC, tomcatA and tomcatB respectively. As the SSO mechanism is based on the assumption that all requests from the same browser are handled by the same container, this will break the SSO, Let me know if I'm misunderstanding some fundermental way in which the jk load balancer works, or if I'm not explaing myself well, Cheers Simon Sorry for my first premature post. I overlooked the followup posts. So the problem here is, that when you switch from one context to another there isn't yet a session on the second context, so the load balancer might send you to a new container. At the moment I see no way of doing such a thing with mod_jk. It could be, that you can use mod_proxy_balancer in this case, because for mod_proxy_balancer the name of the cookie, which helps in the load balancing discussion, is configurable. Sou you could set a SSO-Cookie in the first context with a path of /. It''s something we should think about. Actually I think about adding JkSubWorkerIndicator, which would work analogous to JkWorkerIndicator. So you could set an environment variable in httpd which would contain the name of the balanvcer member, you want to choose. 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 backend via a regexp from the value of your own SSO cookie. But it's not yet implemented. Check mod_proxy_balancer. In general it has less features than mod_jk, but in your case it seems there is an advantage in mod_proxy_balancer. Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk load balancing based upon ip address rather than session id
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 backend via a regexp from the value of your own SSO cookie. But it's not yet implemented. Check mod_proxy_balancer. In general it has less features than mod_jk, but in your case it seems there is an advantage in mod_proxy_balancer. Or just use mod_rewrite to check the request properties, and based on these, rewrite the URL in such a way that it maps to a different JkMount attribute, sending the request to a specific worker. Cheers, Ben - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk load balancing based upon ip address rather than session id
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 the chosen backend via a regexp from the value of your own SSO cookie. But it's not yet implemented. Check mod_proxy_balancer. In general it has less features than mod_jk, but in your case it seems there is an advantage in mod_proxy_balancer. Or just use mod_rewrite to check the request properties, and based on these, rewrite the URL in such a way that it maps to a different JkMount attribute, sending the request to a specific worker. You are right: if he sets e.g. an SSO cookie with the name of the correct node in it and uses mod_rewrite to detect, which is the right node (named NODEX), he can redirect to ORIGINALURL;jsessionid=.NODEX The LB will then send the new request to NODEX, which generates a new session with a correct session id and jvmRoute suffix. Cheers, Ben Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk load balancing based upon ip address rather than session id
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 (and therefore all the rest) go to a particular member. That's exactly it. I want all requests from the same client to be channeled through to the same tomcat instance, regardless of the domain. Sorry for the confusion. You may be able to do this, but you'll certainly have to hack mod_jk in order to do it. I believe there is a method in mod_jk that chooses the jvmRoute for the first (JSESSIONID-less) request. If you were to modify that algorithm, you could achieve your goal, here. I'm a little worried that you might implement a fragile algorithm, though, and end up with an unbalanced load balancer. 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. Do you have options other than using SSO? Come to think of it... how does SSO work when you switch domains with even a single server -- that is, without load balancing in the mix? I would expect that, since you are switching domains, your browser would not send a JSESSIONID cookie to the server, and thus you would not be recognized as having an existing session. ??! I set a tracking gif on each page pointing to a single domain e.g. tracker.first-domain.com this is served up by the same container as an query string argument I pass in the jsessionid for whichever domain the request is made to. For example if the domains have sessions as follows http://child.first-domain.com : JSESSIONID=1234 http://doctor.second-domain.com : JSESSIONID=ABCD http://nurse.third-domain.co.uk : JSESSIONID=wxyz a.jsp on child.first-domain.com html . a href=http://tracker.first-domain.com/track.gif?sid=1234 . /html a.jsp on doctor.second-domain.com html . a href=http://tracker.first-domain.com/track.gif?sid=ABCD . /html etc for nurse.third-domain.co.uk the servlet handling the tracker.first-domain.com/track.gif registers the different domain specific session ids with its own session id and thus ties them altogether, thus when one of the session ids logs on, its associated with a tracker session id which can then propogate the information to the other user sessions. Its a bit rough and ready, but seems to work, I think the tracker gif thing ist the most common way that the web analytics tools work. If you want more info on this I'll happily send you the code its a couple of java files about 400 lines in total. Thanks for your reply, All the best Simon - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk load balancing based upon ip address rather than session id
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 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk load balancing based upon ip address rather than session id
- 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 - 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. This mechanism ties the different session ids in any single container together, regardless if they've originated from different domains, for example: sub1.mydomain.com sub2.yourdomain.com sub3.hisdomain.co.uk No... thats where you going wrong, SSO means a million different things on the web, and some systems do mean that, but on tomcat it means SAME domain, different web apps in same tomcat. When the domain changes, the browser forget the cookie... thats it. The way the load balancer works is that is round robins on the domain... and it maps on context not domain. ie if you call Domain1/Webapp1 Then it will round robin Domain1/Webapp1 (machine1) Domain1/Webapp1 (machine2) Domain1/Webapp1 (machine3) And its the same for other domains ie it round robins between the virtual hosts you have set. If you set STICKY SESSIONS... it still round robins... UNLESS the servlet sets a cookie. As soon as a session comes into play, the client (on that domain) continues to hit the same machine... thus that machine remembers the client state. TC's security uses full domain temp cookies... and the problem is that the security comes before everything else, its no intercept-able. ie that security will prompt before anything else gets at it... or you can get at it. If users never cross a domain... ie a nurse.hospital.com is always in her domain the load balancing will work and so will TC's SSO, if they move between webapps, in that domain. But as soon as nurse.hospital.com links to doctor.hospital.com the browser will not send the cookie and TC will challenge the browser. And then it will round robin in that domain... unless a cookie is set then it sticks. The way some of these other SSO (cross domain systems work)... is they set partial domains... ie .HOSPITAL.COM (with a dot in front) Then that cookie returns across all those domains and they put a JSPECIAL_SESSION_ID in that. Simple... except that you will not get past TC's default security to be able to check it thus the cross domain security systems effectively rebuild all the security. If TC allowed... or a class could be overriden to set a partial cookie it would be cross domain SSO... I'm not sure it can be done easily. And the problem is that if you mess with valves... the custom code may not work in later TC's There are systems out there that do it... but I forget the products... it does mean not using TC's default security. So... If the doctor want to check out the nurse... he has to log on... ;) An interesting thought... if Apache could map... All_Staff.hospital.com/doctor/webapp/ - could be remapped to - doctor.hospital.com/webapp/ All_Staff.hospital.com/nurse/webapp/ - could be remapped to - nurse.hospital.com/webapp/ I wonder if browser and virtual hosting would be happy... ha ha Of course if nurse was a the end of your domain... all your problems (crossing domains) would go away. Nice brain bender... ;) Note that TC actually does it right, because there are all sorts of security considerations when cookies start going cross domain. The other problem is that dotSubDomains... dont work on localhost, so the TC guys probably dont do it because they want to stay sane. Good luck... the problem is only thereif you cross domains... otherwise it works I think. --- Anything said above could be in error --- --- HARBOR : http://www.kewlstuff.co.za/index.htm The most powerful application server on earth. The only real POJO Application Server. See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm --- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk load balancing based upon ip address rather than session id
-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 than a flat load profile that doesn't. ;) | I set a tracking gif on each page pointing to a single domain e.g. | tracker.first-domain.com this is served up by the same container | as an query string argument I pass in the jsessionid for whichever | domain the request is made to. [snip] | the servlet handling the tracker.first-domain.com/track.gif registers | the different domain specific session ids with its own session id and | thus ties them altogether, thus when one of the session ids logs on, | its associated with a tracker session id which can then propogate the | information to the other user sessions. Wow, does that really work? That's a tremendously cool hack, if so! TC should not be respecting the JSESSIONID passed-in if it is invalid. Perhaps I'm misunderstanding you, though. Do you have a registry of session ids cross-linked in the session of each web application? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhSlpUACgkQ9CaO5/Lv0PD5TgCgn9+hn8fghSynKnzJQ4c68mxi ufsAn1MM1S3nI+R4e4baKlBqN/MhtgyC =codo -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk load balancing based upon ip address rather than session id
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 possibly naïve and wrong understanding is as follows : You have a front-end Apache and access the Tomcats via mod_jk and a load balancer. 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 to any of the servers that match the partial domain. The user authentication could be passed to Tomcat via mod_jk (I think it will do that if you ask nicely). Separately, the cross-domain cookie will be passed automatically to Tomcat in the HTTP request headers, which mod_jk also forwards. 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 (not in the Tomcat session object, but e.g. in a database common to all Tomcat instances) ? The separate Tomcats will still each create their separate sessions (and JSESSIONID cookies) for this user session, but does it matter ? And they would be nicely balanced. No ? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk load balancing based upon ip address rather than session id
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 (not in the Tomcat session object, but e.g. in a database common to all Tomcat instances) ? Yes, that kind of thing can be done, but it adds a good bit of complexity and overhead to what is normally just updating a local object. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk load balancing based upon ip address rather than session id
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 to any of the servers that match the partial domain. Your understanding of it, as far as my understanding is concerned, is spot on, but like you say in your post ... 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 So right at the top level (com vs / .com.ar), I'm a bit hamstrung other than that you're completely correct. I read a few other posts about trying to ensure that the JSESSIONID cookie sent by TC applies to the domain name and not the subdomain through TC (rather than doing it through apache) - this one might be of interest to you: http://www.nabble.com/Share-session-cookie-across-subdomains-td16787390.html but regardless in my case this doesn't help me because I'm essentially using two distinct domains. Cheers for the comment though Simon - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk load balancing based upon ip address rather than session id
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 you need to have one request for a resource on each domain to ensure that that session id is tied to the tracking id. Although I can think of several simple ways to overcome this, although in my case I don't need to due to the structure business domain / use cases that the web app models. TC should not be respecting the JSESSIONID passed-in if it is invalid. Perhaps I'm misunderstanding you, though. Do you have a registry of session ids cross-linked in the session of each web application? If I understand you correctly, yes. I use the session ids as a convenient session unique ids in my own registry of user login sessions and a tracking id which happens to be a JSESSIONID. Cheers Simon - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk load balancing based upon ip address rather than session id
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 to try at the Apache level for now. Maybe it will provide an idea of how to do it at the Tomcat level anyway. I imagine that there is a single Apache host, with 3 virtual servers www.mycompany.com www.mycompany.co.uk www.mycompany.ar and the problem is that a browser will not send a cookie to a server whose domain name does not at least partially match. We can also not just set always 3 cookies, because the browser would probably reject a cookie that the host www.mycompany.com would want to set for the domain mycompany.co.uk. On the other hand, there must be a way by which you can tell that it is the same user that just switched from www.mycompany.com to www.mycompany.co.uk. You were talking previously of some scheme based on IP address. That seems a bit dangerous to me, because all requests from behind a router doing NAT will appear to be from the same IP address (but not the same port). Let's imagine thus that when you get a request, you obtain the IP address and port it is made from, and use this combination as a key. Your 3 servers use a common database of user sessions, where each session is identified by such a key. Whenever a server gets a request, it checks the database, and if it finds a matching key, retrieves the info stored under that key, and sets a cookie (with its own domain) which it sends back to the browser. Now the browser, for this new server, will re-send the cookie, and it happens to contain the same information that was set previously by the first server (the one who did the initial authentication and created the initial database entry). Are we getting somewhere ? No, we are not. Because when the browser switches from one server to the other, it might also start another TCP session, to which the router would give another origin port. But wait, it might still work, because the 3 virtual servers share in fact the same IP address, and the router would not know that this is a new session, because it works on the base of IP addresses, and does not look at the Host: HTTP headers. I have no idea how fragile this is, but maybe it gives you some additional ideas ? (It probably is quite fragile, because it depends on the browser and server maintaining the same TCP session throughout.) But now wait again. Do you know about OpenID ? That may be what you are looking for, and avoid all the stuff above. In your case, you would run your own OpenID server, and it would authenticate users no matter on which server they start, and keep this authentication available for the other (registered) servers. Go to http://openid.net; André - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk load balancing based upon ip address rather than session id
-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 breaks the | assumption that the SSO mechanism relies upon (that all sessions being | held in a single container). | | The tomcat instances aren't in a distributed cluster and I'd like to | keep it that way. Isn't this what sticky sessions are for? You get randomly assigned to a server for your first request, and each subsequent request goes to that same server (unless it goes down, in which case you have to switch). This does not require distributable sessions. Does that not solve your SSO requirement? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhRiRMACgkQ9CaO5/Lv0PBzbwCgl5lX0EKRYqpjR040//ChN95O sHAAnj4/xoTrHto0be4XjXWc6AAuUmn1 =LZXJ -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk load balancing based upon ip address rather than session id
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 | assumption that the SSO mechanism relies upon (that all sessions being | held in a single container). | | The tomcat instances aren't in a distributed cluster and I'd like to | keep it that way. Isn't this what sticky sessions are for? You get randomly assigned to a server for your first request, and each subsequent request goes to that same server (unless it goes down, in which case you have to switch). This does not require distributable sessions. Does that not solve your SSO requirement? - -chris 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 sent as part of the request the node is chosen according to the worker.loadbalancer.method (Request, Session, Traffic, Busyness i think Request is the default) . Once a JSESSIONID has been set by a container the load balancer will then attach the JVMRoute onto the end which will then be used by the jk load balancer in future requests to determine the node to use to service the request. e.g. if I have three nodes (tomcatA, tomcatB, tomcatC) I could have the following scenario... child.first-domain.com : JSESSIONID = D75AA77AC6FBF43F2C2DDC195DDA6D44.tomcatC doctor.second-domain.com : JSESSIONID = 5D211C177DFB064DEF731832CF07D693.tomcatA nurse.third-domain.co.uk : JSESSIONID = E1EC672CAAA3F2F8348C2A23991DF46B.tomcatB Where my browser has made three seperate requests for three seperate resources, all serviced by the same group of tomcat containers through vhosting, behind the load balancer, in which case my SSO mechanism won't work as future requests on child.first-domain.com, doctor.second-domain.com and nurse.third-domain.co.uk will behandled by tomcatC, tomcatA and tomcatB respectively. As the SSO mechanism is based on the assumption that all requests from the same browser are handled by the same container, this will break the SSO, Let me know if I'm misunderstanding some fundermental way in which the jk load balancer works, or if I'm not explaing myself well, Cheers Simon - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk load balancing based upon ip address rather than session id
-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 instigates a session creation, if no JSESSIONID cookie was sent | as part of the request the node is chosen according to the | worker.loadbalancer.method (Request, Session, Traffic, Busyness i | think Request is the default). I'm a little unclear on the details within mod_jk, but yes, that's the idea. | Once a JSESSIONID has been set by a | container the load balancer will then attach the JVMRoute onto the | end which will then be used by the jk load balancer in future requests | to determine the node to use to service the request. e.g. if I have | three nodes (tomcatA, tomcatB, tomcatC) I could have the following | scenario... | | child.first-domain.com : JSESSIONID = D75AA77AC6FBF43F2C2DDC195DDA6D44.tomcatC | doctor.second-domain.com : JSESSIONID = 5D211C177DFB064DEF731832CF07D693.tomcatA | nurse.third-domain.co.uk : JSESSIONID = E1EC672CAAA3F2F8348C2A23991DF46B.tomcatB Hmm... I'm beginning to see the problem. That wasn't entirely clear from your original post. Since you want to use SSO, I'm assuming that you are running all three (or more) applications in the same instance of Tomcat, even though there are multiple instances of Tomcat at work (on separate servers, presumably). The first request to each of these domain names does not include a cookie because the domains do not match. Each initial request to the distinct domains causes a fresh random choice amongst the servers, so you are not likely to get lucky and have all your initial requests randomly end up at the same server, and therefore SSO fails. :( | Let me know if I'm misunderstanding some fundermental way in which the | jk load balancer works, or if I'm not explaing myself well, No, you were right... I just wasn't understanding your initial question. 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 (and therefore all the rest) go to a particular member. You may be able to do this, but you'll certainly have to hack mod_jk in order to do it. I believe there is a method in mod_jk that chooses the jvmRoute for the first (JSESSIONID-less) request. If you were to modify that algorithm, you could achieve your goal, here. I'm a little worried that you might implement a fragile algorithm, though, and end up with an unbalanced load balancer. Do you have options other than using SSO? Come to think of it... how does SSO work when you switch domains with even a single server -- that is, without load balancing in the mix? I would expect that, since you are switching domains, your browser would not send a JSESSIONID cookie to the server, and thus you would not be recognized as having an existing session. ??! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhRqswACgkQ9CaO5/Lv0PDukQCeMKv8qpvuvKsag1AMLWqsaNSV GA4An19MrUrE/FPRTGMpWvNSLgF5Zs3K =n6yV -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
