Re: session problems when using mod_jk (1.2.14) load balancing
Hi, I'm using the domain property in the same situation as the one discussed in this thread. Any reason why I shouldn't use the domain property and rely on the worker names instead? Thanks in advance, -- Edgar Alves Rainer Jung wrote: That should not work! The correct way to configure session stickyness is to use jvmRoute (which you already did) and then giving the workers the same names as the jvmRoute. That is instead of bl_worker_dev use dev_alexis and instead of bl_worker_noah use noah_alexis as the worker names. You should check, that the URLs produced by your application include the ;jsessionid=32Characters.jvmRoute or - in case you use cookies - the same info is in your session cookie. mod_jk then automatically strips the jvmRoute part from the session identifier and lloks for a worker of the same name. You will only need to use the domain attribute in case you have a lot of tomcat instances and some of them have the sessions replicated, others not. Then you can give all members of a replication domain the same domain name and mod_jk will know, that in case the correct worker is down, which alternatives are good. Beautiful - worked like a charm. That might take the cake as far as longest question to quickest, shortest answer goes. ha. Thanks a bunch. I might have to gripe about doucmentation in a second (nother thread).. Noah Edgar Alves wrote: Try adding these two lines to worker.properties: worker.bl_worker_dev.domain=dev_alexis worker.bl_worker_noah.domain=noah_alexis -- Edgar Alves - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session problems when using mod_jk (1.2.14) load balancing
Edgar Alves wrote: Hi, I'm using the domain property in the same situation as the one discussed in this thread. Any reason why I shouldn't use the domain property and rely on the worker names instead? Domain is supposed to be used with multiple workers sharing the same jvmRoute having session replication between them, thus forming 'cluster groups' to lower the session data replication transfer. You can use the domain, but it's a trick rather then a proper usage. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session problems when using mod_jk (1.2.14) load balancing
Hi Mladen, I've used the domain property because it seemed the more general approach (i.e., supports clusters but can be used with a single worker). What this thread got me curious about is if using the domain property in this fashion is officially supported, or on the other hand if it can only be used reliably with clusters. After reading the documentation (http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html), I got the idea that using the domain property with only one worker wouldn't be a trick but another way tell mod_jk which jvmRoute to use: If sticky_session is used, then the domain name is used as session route.. Naming the worker after the intended jvmRoute (even though it used to be the only way) seems more of a trick than explicitly specifying the jvmRoute with the domain property. However, since the same documention mentions that the domain property is used for large systems with clustering, do you know of any side effects (like lower performance) of using this approach as opposed to simply naming the workers after the jvmRoute? -- Edgar Alves Mladen Turk wrote: Edgar Alves wrote: Hi, I'm using the domain property in the same situation as the one discussed in this thread. Any reason why I shouldn't use the domain property and rely on the worker names instead? Domain is supposed to be used with multiple workers sharing the same jvmRoute having session replication between them, thus forming 'cluster groups' to lower the session data replication transfer. You can use the domain, but it's a trick rather then a proper usage. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session problems when using mod_jk (1.2.14) load balancing
OK, thanks Mladen: I have to correct myself. 1) Traditional use Until mod_jk 1.2.6 there was no concept of domains. You had to specify the worker name to be exactly the same as the jvmRoute to make sticky sessions work. This way of configuring stickyness is wel known to mod_jk users. 2) I introduced domains to allow mod_jk to make good failover decisions in the case where you have many tomcats, but session replication only between subset, like 2 Tomcat clusters with three instances each (T1_1, T1_2, ..., T3_3) where T1_1, T1_2 and T1_3 replicate their sessions between each other etc. Then you can configure a common domain name for T1_1, T1_2 and T1_3 (e.g. T1) and is mod_jk is not able to correctly route a sticky request (e.g. T1_1 goes down) it will choose another worker with the same domain name. Moreover in this case it will load balance betweeen all those workers (in my example between T1_2 and T1_3). 1) and 2) still work in 1.2.14. 3) Mladen improved mod_jk a lot and during that time introduced another additional way of using the domain attribute: If stickyness for sessions is required and mod_jk does not find a worker with the name of the jvmRoute contained in the session id, then it will next try to find any worker whose domain name is equal to the jvmRoute. If there are multiple such workers, mod_jk loadbalances between them. Summary: If there is a one-to-one relationship between jvmRoutes and workers, there is no functional difference between giving the worker the same name as the jvmRoute, or giving it the same domain attribute as the jvmRoute. The first way is more compatible with what people used to do since a long time and it will be marginally faster, because that check is done first. It's always good to look at the code, in fact when I first discovered the use of the jvmRoute as a domain name in the code I thought it's a bug. I now understand, that it's at least a feature :-) Hi Mladen, I've used the domain property because it seemed the more general approach (i.e., supports clusters but can be used with a single worker). What this thread got me curious about is if using the domain property in this fashion is officially supported, or on the other hand if it can only be used reliably with clusters. After reading the documentation (http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html), I got the idea that using the domain property with only one worker wouldn't be a trick but another way tell mod_jk which jvmRoute to use: If sticky_session is used, then the domain name is used as session route.. Naming the worker after the intended jvmRoute (even though it used to be the only way) seems more of a trick than explicitly specifying the jvmRoute with the domain property. However, since the same documention mentions that the domain property is used for large systems with clustering, do you know of any side effects (like lower performance) of using this approach as opposed to simply naming the workers after the jvmRoute? -- Edgar Alves Mladen Turk wrote: Edgar Alves wrote: Hi, I'm using the domain property in the same situation as the one discussed in this thread. Any reason why I shouldn't use the domain property and rely on the worker names instead? Domain is supposed to be used with multiple workers sharing the same jvmRoute having session replication between them, thus forming 'cluster groups' to lower the session data replication transfer. You can use the domain, but it's a trick rather then a proper usage. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session problems when using mod_jk (1.2.14) load balancing
Try adding these two lines to worker.properties: worker.bl_worker_dev.domain=dev_alexis worker.bl_worker_noah.domain=noah_alexis -- Edgar Alves Mott Leroy wrote: Hi - I'm unable to get mod_jk load balancing working. The usual mod_jk setup works just fine, but using a load balancing worker however, is not. [Oddly, my webserver crashed during testing of this, but that could very well be unrelated] The problem is with user sessions. The instances (nodes) do not seem to recognize an already established session with the user and are creating new sessions. It's possible that is a session-stickiness issue, but it appears like the requests are hitting the same instance, just not getting the previously established session. As a result, I can't even reliably login to my application. I created a session listener for debugging purposes and it reports -no- destroyed sessions, but plenty of newly created sessions on both instances that make up the cluster. The session IDs, I noticed, have the jvmRoute name attached to them, which should be a good sign. I have a webserver running Apache (1.3.33), mod_jk (1.2.14), and an application server running the cluster -- 2 instances tomcat (5.0.28) on different ports. I added a unique jvmRoute to both instances in the server.xml: Engine name=Catalina defaultHost=localhost jvmRoute=dev_alexis Engine name=Catalina defaultHost=localhost jvmRoute=noah_alexis My worker.properties loadbalancer settings: worker.list=load_balancer_test worker.load_balancer_test.type=lb worker.load_balancer_test.balance_workers=bl_worker_dev,bl_worker_noah worker.load_balancer_test.sticky_session=true worker.load_balancer_test.sticky_session_force=false worker.bl_worker_dev.type=ajp13 worker.bl_worker_dev.host=alexis worker.bl_worker_dev.port=9003 worker.bl_worker_dev.lbfactor=1 worker.bl_worker_dev.socket_keepalive=1 worker.bl_worker_dev.recycle_timeout=300 worker.bl_worker_noah.type=ajp13 worker.bl_worker_noah.host=alexis worker.bl_worker_noah.port=8063 worker.bl_worker_noah.lbfactor=3 worker.bl_worker_noah.socket_keepalive=1 worker.bl_worker_noah.recycle_timeout=300 Any ideas, things I could try would be much appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session problems when using mod_jk (1.2.14) load balancing
Beautiful - worked like a charm. That might take the cake as far as longest question to quickest, shortest answer goes. ha. Thanks a bunch. I might have to gripe about doucmentation in a second (nother thread).. Noah Edgar Alves wrote: Try adding these two lines to worker.properties: worker.bl_worker_dev.domain=dev_alexis worker.bl_worker_noah.domain=noah_alexis -- Edgar Alves Mott Leroy wrote: Hi - I'm unable to get mod_jk load balancing working. The usual mod_jk setup works just fine, but using a load balancing worker however, is not. [Oddly, my webserver crashed during testing of this, but that could very well be unrelated] The problem is with user sessions. The instances (nodes) do not seem to recognize an already established session with the user and are creating new sessions. It's possible that is a session-stickiness issue, but it appears like the requests are hitting the same instance, just not getting the previously established session. As a result, I can't even reliably login to my application. I created a session listener for debugging purposes and it reports -no- destroyed sessions, but plenty of newly created sessions on both instances that make up the cluster. The session IDs, I noticed, have the jvmRoute name attached to them, which should be a good sign. I have a webserver running Apache (1.3.33), mod_jk (1.2.14), and an application server running the cluster -- 2 instances tomcat (5.0.28) on different ports. I added a unique jvmRoute to both instances in the server.xml: Engine name=Catalina defaultHost=localhost jvmRoute=dev_alexis Engine name=Catalina defaultHost=localhost jvmRoute=noah_alexis My worker.properties loadbalancer settings: worker.list=load_balancer_test worker.load_balancer_test.type=lb worker.load_balancer_test.balance_workers=bl_worker_dev,bl_worker_noah worker.load_balancer_test.sticky_session=true worker.load_balancer_test.sticky_session_force=false worker.bl_worker_dev.type=ajp13 worker.bl_worker_dev.host=alexis worker.bl_worker_dev.port=9003 worker.bl_worker_dev.lbfactor=1 worker.bl_worker_dev.socket_keepalive=1 worker.bl_worker_dev.recycle_timeout=300 worker.bl_worker_noah.type=ajp13 worker.bl_worker_noah.host=alexis worker.bl_worker_noah.port=8063 worker.bl_worker_noah.lbfactor=3 worker.bl_worker_noah.socket_keepalive=1 worker.bl_worker_noah.recycle_timeout=300 Any ideas, things I could try would be much appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session problems when using mod_jk (1.2.14) load balancing
That should not work! The correct way to configure session stickyness is to use jvmRoute (which you already did) and then giving the workers the same names as the jvmRoute. That is instead of bl_worker_dev use dev_alexis and instead of bl_worker_noah use noah_alexis as the worker names. You should check, that the URLs produced by your application include the ;jsessionid=32Characters.jvmRoute or - in case you use cookies - the same info is in your session cookie. mod_jk then automatically strips the jvmRoute part from the session identifier and lloks for a worker of the same name. You will only need to use the domain attribute in case you have a lot of tomcat instances and some of them have the sessions replicated, others not. Then you can give all members of a replication domain the same domain name and mod_jk will know, that in case the correct worker is down, which alternatives are good. Beautiful - worked like a charm. That might take the cake as far as longest question to quickest, shortest answer goes. ha. Thanks a bunch. I might have to gripe about doucmentation in a second (nother thread).. Noah Edgar Alves wrote: Try adding these two lines to worker.properties: worker.bl_worker_dev.domain=dev_alexis worker.bl_worker_noah.domain=noah_alexis -- Edgar Alves Mott Leroy wrote: Hi - I'm unable to get mod_jk load balancing working. The usual mod_jk setup works just fine, but using a load balancing worker however, is not. [Oddly, my webserver crashed during testing of this, but that could very well be unrelated] The problem is with user sessions. The instances (nodes) do not seem to recognize an already established session with the user and are creating new sessions. It's possible that is a session-stickiness issue, but it appears like the requests are hitting the same instance, just not getting the previously established session. As a result, I can't even reliably login to my application. I created a session listener for debugging purposes and it reports -no- destroyed sessions, but plenty of newly created sessions on both instances that make up the cluster. The session IDs, I noticed, have the jvmRoute name attached to them, which should be a good sign. I have a webserver running Apache (1.3.33), mod_jk (1.2.14), and an application server running the cluster -- 2 instances tomcat (5.0.28) on different ports. I added a unique jvmRoute to both instances in the server.xml: Engine name=Catalina defaultHost=localhost jvmRoute=dev_alexis Engine name=Catalina defaultHost=localhost jvmRoute=noah_alexis My worker.properties loadbalancer settings: worker.list=load_balancer_test worker.load_balancer_test.type=lb worker.load_balancer_test.balance_workers=bl_worker_dev,bl_worker_noah worker.load_balancer_test.sticky_session=true worker.load_balancer_test.sticky_session_force=false worker.bl_worker_dev.type=ajp13 worker.bl_worker_dev.host=alexis worker.bl_worker_dev.port=9003 worker.bl_worker_dev.lbfactor=1 worker.bl_worker_dev.socket_keepalive=1 worker.bl_worker_dev.recycle_timeout=300 worker.bl_worker_noah.type=ajp13 worker.bl_worker_noah.host=alexis worker.bl_worker_noah.port=8063 worker.bl_worker_noah.lbfactor=3 worker.bl_worker_noah.socket_keepalive=1 worker.bl_worker_noah.recycle_timeout=300 Any ideas, things I could try would be much appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session problems when using mod_jk (1.2.14) load balancing
Ok - noted. I changed it. It works without the domain as you noted. Thanks. Rainer Jung wrote: That should not work! The correct way to configure session stickyness is to use jvmRoute (which you already did) and then giving the workers the same names as the jvmRoute. That is instead of bl_worker_dev use dev_alexis and instead of bl_worker_noah use noah_alexis as the worker names. You should check, that the URLs produced by your application include the ;jsessionid=32Characters.jvmRoute or - in case you use cookies - the same info is in your session cookie. mod_jk then automatically strips the jvmRoute part from the session identifier and lloks for a worker of the same name. You will only need to use the domain attribute in case you have a lot of tomcat instances and some of them have the sessions replicated, others not. Then you can give all members of a replication domain the same domain name and mod_jk will know, that in case the correct worker is down, which alternatives are good. Beautiful - worked like a charm. That might take the cake as far as longest question to quickest, shortest answer goes. ha. Thanks a bunch. I might have to gripe about doucmentation in a second (nother thread).. Noah Edgar Alves wrote: Try adding these two lines to worker.properties: worker.bl_worker_dev.domain=dev_alexis worker.bl_worker_noah.domain=noah_alexis -- Edgar Alves Mott Leroy wrote: Hi - I'm unable to get mod_jk load balancing working. The usual mod_jk setup works just fine, but using a load balancing worker however, is not. [Oddly, my webserver crashed during testing of this, but that could very well be unrelated] The problem is with user sessions. The instances (nodes) do not seem to recognize an already established session with the user and are creating new sessions. It's possible that is a session-stickiness issue, but it appears like the requests are hitting the same instance, just not getting the previously established session. As a result, I can't even reliably login to my application. I created a session listener for debugging purposes and it reports -no- destroyed sessions, but plenty of newly created sessions on both instances that make up the cluster. The session IDs, I noticed, have the jvmRoute name attached to them, which should be a good sign. I have a webserver running Apache (1.3.33), mod_jk (1.2.14), and an application server running the cluster -- 2 instances tomcat (5.0.28) on different ports. I added a unique jvmRoute to both instances in the server.xml: Engine name=Catalina defaultHost=localhost jvmRoute=dev_alexis Engine name=Catalina defaultHost=localhost jvmRoute=noah_alexis My worker.properties loadbalancer settings: worker.list=load_balancer_test worker.load_balancer_test.type=lb worker.load_balancer_test.balance_workers=bl_worker_dev,bl_worker_noah worker.load_balancer_test.sticky_session=true worker.load_balancer_test.sticky_session_force=false worker.bl_worker_dev.type=ajp13 worker.bl_worker_dev.host=alexis worker.bl_worker_dev.port=9003 worker.bl_worker_dev.lbfactor=1 worker.bl_worker_dev.socket_keepalive=1 worker.bl_worker_dev.recycle_timeout=300 worker.bl_worker_noah.type=ajp13 worker.bl_worker_noah.host=alexis worker.bl_worker_noah.port=8063 worker.bl_worker_noah.lbfactor=3 worker.bl_worker_noah.socket_keepalive=1 worker.bl_worker_noah.recycle_timeout=300 Any ideas, things I could try would be much appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
