Re: mod jk - multiple applications, different server clusers, sticky sessions
-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 Connectors 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod jk - multiple applications, different server clusers, sticky sessions
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod jk - multiple applications, different server clusers, sticky sessions
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod jk - multiple applications, different server clusers, sticky sessions
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod jk - multiple applications, different server clusers, sticky sessions
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
mod jk - multiple applications, different server clusers, sticky sessions
Hello, 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 sticky_session_force is set, then another server is tried; however, the 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. 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? 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? Thanks in advance, Jason Wright -- Jason Wright TCN Systems Administrator jason.wri...@tcnbroadcasting.com Office (866) 745-1901 x123 Cell (801) 687-3260
