patch: mod_jk load balance algorithm that accounts for current worker load
mod_jk developers: We have been using mod_jk for some time, (1.2.8, 1.2.10, and now 1.2.14), with Apache 2.0.50, Tomcat 5.5.9, under fedora (2.4.22 kernel). We have 6 tomcats as balanced workers, and we're using lb.method=[R]equest. When load testing our tomcats individually, they can handle about 10 requests per second. Our application is completely parallel, nothing is shared (no database). However, when we test against the load balancer, it starts out okay, but degrades to about 12 to 16 requests per second overall. It should be getting somewhere between 50 and 60 requests per second (6 servers * 10 requests per second each). With mod_jk 1.2.14 we were able to check the (very helpful) jkstatus page, and we noticed that the Busy column was very high for the lagging server, yet mod_jk kept giving it more requests, while other servers were sitting with 0 Busy. We tried both optimistic and pessimistic locking modes; pessimistic may have been slightly better but it was hard to say. We added a simple load balancing algorithm (to common/jk_lb_worker.c) that takes into account the busyness of each worker and its lbfactor, and picks the worker with the lowest current load. It ignores the Load Balancer Value. This simple algorithm improved our test from 12-16 requests per second to 60+ requests per second, and watching the jkstatus page showed that all servers were kept evenly busy. If one particular server slowed down, its Busy value increased, so it received fewer requests. We'd like to submit our patch to mod_jk. We've added a new workers.properties lb.method option -- lb.method=B for Busyness, and updated the jkstatus display page accordingly. I wanted to get any feedback or suggestions from the mailing list before submitting the patch to bugzilla. Thanks, Chris Lamprecht - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: patch: mod_jk load balance algorithm that accounts for current worker load
Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. Your questions and concerns are important to us and we are dedicated to assisting you in anyway possible. In order to assist you in the most efficient and timely manner, all email correspondence must be submitted through our online email form. To locate our online email form, we ask that you visit our Help Desk at Customer Support at www.ballystore.com/helpdesk and choose FAQ/Contact Us under Online Store Information. Then, choose the subject that will address your question and send us an email through our online email form. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: mod_jk developers: We have been using mod_jk for some time, (1.2.8, 1.2.10, and now 1.2.14), with Apache 2.0.50, Tomcat 5.5.9, under fedora (2.4.22 kernel). We have 6 tomcats as balanced workers, and we're using lb.method=[R]equest. When load testing our tomcats individually, they can handle about 10 requests per second. Our application is completely parallel, nothing is shared (no database). However, when we test against the load balancer, it starts out okay, but degrades to about 12 to 16 requests per second overall. It should be getting somewhere between 50 and 60 requests per second (6 servers * 10 requests per second each). With mod_jk 1.2.14 we were able to check the (very helpful) jkstatus page, and we noticed that the Busy column was very high for the lagging server, yet mod_jk kept giving it more requests, while other servers were sitting with 0 Busy. We tried both optimistic and pessimistic locking modes; pessimistic may have been slightly better but it was hard to say. We added a simple load balancing algorithm (to common/jk_lb_worker.c) that takes into account the busyness of each worker and its lbfactor, and picks the worker with the lowest current load. It ignores the Load Balancer Value. This simple algorithm improved our test from 12-16 requests per second to 60+ requests per second, and watching the jkstatus page showed that all servers were kept evenly busy. If one particular server slowed down, its Busy value increased, so it received fewer requests. We'd like to submit our patch to mod_jk. We've added a new workers.properties lb.method option -- lb.method=B for Busyness, and updated the jkstatus display page accordingly. I wanted to get any feedback or suggestions from the mailing list before submitting the patch to bugzilla. Thanks, Chris Lamprecht - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message, including any attachments, is solely for the use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution of this communication is expressly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy any and all copies of the original message. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE: patch: mod_jk load balance algorithm that accounts for current worker load
Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. Your questions and concerns are important to us and we are dedicated to assisting you in anyway possible. In order to assist you in the most efficient and timely manner, all email correspondence must be submitted through our online email form. To locate our online email form, we ask that you visit our Help Desk at Customer Support at www.ballystore.com/helpdesk and choose FAQ/Contact Us under Online Store Information. Then, choose the subject that will address your question and send us an email through our online email form. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. Your questions and concerns are important to us and we are dedicated to assisting you in anyway possible. In order to assist you in the most efficient and timely manner, all email correspondence must be submitted through our online email form. To locate our online email form, we ask that you visit our Help Desk at Customer Support at www.ballystore.com/helpdesk and choose FAQ/Contact Us under Online Store Information. Then, choose the subject that will address your question and send us an email through our online email form. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: mod_jk developers: We have been using mod_jk for some time, (1.2.8, 1.2.10, and now 1.2.14), with Apache 2.0.50, Tomcat 5.5.9, under fedora (2.4.22 kernel). We have 6 tomcats as balanced workers, and we're using lb.method=[R]equest. When load testing our tomcats individually, they can handle about 10 requests per second. Our application is completely parallel, nothing is shared (no database). However, when we test against the load balancer, it starts out okay, but degrades to about 12 to 16 requests per second overall. It should be getting somewhere between 50 and 60 requests per second (6 servers * 10 requests per second each). With mod_jk 1.2.14 we were able to check the (very helpful) jkstatus page, and we noticed that the Busy column was very high for the lagging server, yet mod_jk kept giving it more requests, while other servers were sitting with 0 Busy. We tried both optimistic and pessimistic locking modes; pessimistic may have been slightly better but it was hard to say. We added a simple load balancing algorithm (to common/jk_lb_worker.c) that takes into account the busyness of each worker and its lbfactor, and picks the worker with the lowest current load. It ignores the Load Balancer Value. This simple algorithm improved our test from 12-16 requests per second to 60+ requests per second, and watching the jkstatus page showed that all servers were kept evenly busy. If one particular server slowed down, its Busy value increased, so it received fewer requests. We'd like to submit our patch to mod_jk. We've added a new workers.properties lb.method option -- lb.method=B for Busyness, and updated the jkstatus display page accordingly. I wanted to get any feedback or suggestions from the mailing list before submitting the patch to bugzilla. Thanks, Chris Lamprecht - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message, including any attachments, is solely for the use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution of this communication is expressly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy any and all copies of the original message. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message, including any attachments, is solely for the use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution of this communication is expressly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy any and all copies of the original message. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE: RE: patch: mod_jk load balance algorithm that accounts for current worker load
Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. Your questions and concerns are important to us and we are dedicated to assisting you in anyway possible. In order to assist you in the most efficient and timely manner, all email correspondence must be submitted through our online email form. To locate our online email form, we ask that you visit our Help Desk at Customer Support at www.ballystore.com/helpdesk and choose FAQ/Contact Us under Online Store Information. Then, choose the subject that will address your question and send us an email through our online email form. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. Your questions and concerns are important to us and we are dedicated to assisting you in anyway possible. In order to assist you in the most efficient and timely manner, all email correspondence must be submitted through our online email form. To locate our online email form, we ask that you visit our Help Desk at Customer Support at www.ballystore.com/helpdesk and choose FAQ/Contact Us under Online Store Information. Then, choose the subject that will address your question and send us an email through our online email form. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. Your questions and concerns are important to us and we are dedicated to assisting you in anyway possible. In order to assist you in the most efficient and timely manner, all email correspondence must be submitted through our online email form. To locate our online email form, we ask that you visit our Help Desk at Customer Support at www.ballystore.com/helpdesk and choose FAQ/Contact Us under Online Store Information. Then, choose the subject that will address your question and send us an email through our online email form. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: mod_jk developers: We have been using mod_jk for some time, (1.2.8, 1.2.10, and now 1.2.14), with Apache 2.0.50, Tomcat 5.5.9, under fedora (2.4.22 kernel). We have 6 tomcats as balanced workers, and we're using lb.method=[R]equest. When load testing our tomcats individually, they can handle about 10 requests per second. Our application is completely parallel, nothing is shared (no database). However, when we test against the load balancer, it starts out okay, but degrades to about 12 to 16 requests per second overall. It should be getting somewhere between 50 and 60 requests per second (6 servers * 10 requests per second each). With mod_jk 1.2.14 we were able to check the (very helpful) jkstatus page, and we noticed that the Busy column was very high for the lagging server, yet mod_jk kept giving it more requests, while other servers were sitting with 0 Busy. We tried both optimistic and pessimistic locking modes; pessimistic may have been slightly better but it was hard to say. We added a simple load balancing algorithm (to common/jk_lb_worker.c) that takes into account the busyness of each worker and its lbfactor, and picks the worker with the lowest current load. It ignores the Load Balancer Value. This simple algorithm improved our test from 12-16 requests per second to 60+ requests per second, and watching the jkstatus page showed that all servers were kept evenly busy. If one particular server slowed down, its Busy value increased, so it received fewer requests. We'd like to submit our patch to mod_jk. We've added a new workers.properties lb.method option -- lb.method=B for Busyness, and updated the jkstatus display page accordingly. I wanted to get any feedback or suggestions from the mailing list before submitting the patch to bugzilla. Thanks, Chris Lamprecht - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message, including any attachments, is solely for the use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution of this communication is expressly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy any and all copies of the original message. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message, including any
RE: RE: RE: RE: patch: mod_jk load balance algorithm that accounts for current worker load
Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. Your questions and concerns are important to us and we are dedicated to assisting you in anyway possible. In order to assist you in the most efficient and timely manner, all email correspondence must be submitted through our online email form. To locate our online email form, we ask that you visit our Help Desk at Customer Support at www.ballystore.com/helpdesk and choose FAQ/Contact Us under Online Store Information. Then, choose the subject that will address your question and send us an email through our online email form. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. Your questions and concerns are important to us and we are dedicated to assisting you in anyway possible. In order to assist you in the most efficient and timely manner, all email correspondence must be submitted through our online email form. To locate our online email form, we ask that you visit our Help Desk at Customer Support at www.ballystore.com/helpdesk and choose FAQ/Contact Us under Online Store Information. Then, choose the subject that will address your question and send us an email through our online email form. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. Your questions and concerns are important to us and we are dedicated to assisting you in anyway possible. In order to assist you in the most efficient and timely manner, all email correspondence must be submitted through our online email form. To locate our online email form, we ask that you visit our Help Desk at Customer Support at www.ballystore.com/helpdesk and choose FAQ/Contact Us under Online Store Information. Then, choose the subject that will address your question and send us an email through our online email form. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: Dear Valued Customer, Thank you for contacting Customer Support at www.ballystore.com. Your questions and concerns are important to us and we are dedicated to assisting you in anyway possible. In order to assist you in the most efficient and timely manner, all email correspondence must be submitted through our online email form. To locate our online email form, we ask that you visit our Help Desk at Customer Support at www.ballystore.com/helpdesk and choose FAQ/Contact Us under Online Store Information. Then, choose the subject that will address your question and send us an email through our online email form. We apologize for any inconvenience this may cause you. Sincerely, Customer Support at www.ballystore.com Original Message Follows: mod_jk developers: We have been using mod_jk for some time, (1.2.8, 1.2.10, and now 1.2.14), with Apache 2.0.50, Tomcat 5.5.9, under fedora (2.4.22 kernel). We have 6 tomcats as balanced workers, and we're using lb.method=[R]equest. When load testing our tomcats individually, they can handle about 10 requests per second. Our application is completely parallel, nothing is shared (no database). However, when we test against the load balancer, it starts out okay, but degrades to about 12 to 16 requests per second overall. It should be getting somewhere between 50 and 60 requests per second (6 servers * 10 requests per second each). With mod_jk 1.2.14 we were able to check the (very helpful) jkstatus page, and we noticed that the Busy column was very high for the lagging server, yet mod_jk kept giving it more requests, while other servers were sitting with 0 Busy. We tried both optimistic and pessimistic locking modes; pessimistic may have been slightly better but it was hard to say. We added a simple load balancing algorithm (to common/jk_lb_worker.c) that takes into account the busyness of each worker and its lbfactor, and picks the worker with the lowest current load. It ignores the Load Balancer Value. This simple algorithm improved our test from 12-16 requests per second to 60+ requests per second, and watching the jkstatus page showed that all servers were kept evenly busy. If one particular server slowed down, its Busy value increased, so it received fewer requests. We'd like to submit our patch to mod_jk. We've added a new workers.properties lb.method option -- lb.method=B for Busyness, and updated the jkstatus display page accordingly. I wanted to get any feedback or suggestions from the mailing list before submitting the patch to bugzilla. Thanks, Chris
DO NOT REPLY [Bug 36055] - HTTPS connection does not work without sslProtocol attribute
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36055. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36055 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-08-06 10:48 --- This was fixed a few months ago and is included in 5.5.10 onwards. See http://marc.theaimsgroup.com/?l=tomcat-devm=111809350408866w=2 for details. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36057] New: - The method 'getUserPrincipal()' in class 'org.apache.catalina.connector.Request' returns a not null value after the session has been invalidated and/or recreated
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36057. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36057 Summary: The method 'getUserPrincipal()' in class 'org.apache.catalina.connector.Request' returns a not null value after the session has been invalidated and/or recreated Product: Tomcat 5 Version: 5.5.9 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] When you invalidate the session with a call to the method 'session.invalidate()' and/or recreate it with a call to the method 'request.getSession(true)', a call to the method 'request.getUserPrincipal()' continues to return a not null value just after. To solve this problem, I think you should reinitialize the value of the field 'userPrincipal' to 'null' in the method 'doGetSession(boolean create)' of the class 'org.apache.catalina.connector.Request' when the parameter 'create' is equal to 'true'. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: patch: mod_jk load balance algorithm that accounts for current worker load
Chris Lamprecht wrote: mod_jk developers: We have been using mod_jk for some time, (1.2.8, 1.2.10, and now 1.2.14), with Apache 2.0.50, Tomcat 5.5.9, under fedora (2.4.22 kernel). We have 6 tomcats as balanced workers, and we're using lb.method=[R]equest. Great! Can you open an bugzilla entry for Native:JK and attach the patch. Please file that as enhancement. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36057] - The method 'getUserPrincipal()' in class 'org.apache.catalina.connector.Request' returns a not null value after the session has been invalidated and/or recreated
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36057. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36057 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-08-06 21:25 --- Section 12.5.3.1 of the servlet spec is clear that the logout of a Form-auth user by invalidating the session applies to subsequent requests only. If you need this fuctionality in your webapp, you can easily get it by wrapping the Request at the same time that you invalidate the session. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
