DO NOT REPLY [Bug 35264] - Typo and slight inconsistency in jk locking constants
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=35264. 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=35264 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-06-09 10:16 --- Fixed in the CVS. -- 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 35264] - Typo and slight inconsistency in jk locking constants
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=35264. 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=35264 --- Additional Comments From [EMAIL PROTECTED] 2005-06-08 11:32 --- Created an attachment (id=15332) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15332action=view) Small patch for shm locking -- 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 35264] - Typo and slight inconsistency in jk locking constants
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=35264. 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=35264 --- Additional Comments From [EMAIL PROTECTED] 2005-06-08 20:02 --- No, It should mean 1 pessimistic (locking shared memory on each access) and 0 (default or optimistic) meaning no lock are needed. Your patch is forcing pessimistic locking which should be used only if interested in high accuracy for multi cpu boxes. I can only agree on the copy/paste typo for -return JK_LB_BYREQUESTS; +return JK_LB_LOCK_DEFAULT; That BTW would lead to the same behaviour because both defines are 0 so there are no functional difference. -- 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 35264] - Typo and slight inconsistency in jk locking constants
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=35264. 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=35264 --- Additional Comments From [EMAIL PROTECTED] 2005-06-08 21:57 --- No, It should mean 1 pessimistic (locking shared memory on each access) and 0 (default or optimistic) meaning no lock are needed. Your patch is forcing pessimistic locking which should be used only if interested in high accuracy for multi cpu boxes. I definitely don't want to change the default behaviour. As I understand the code, the numerical values of the constants JK_LB_LOCK_DEFAULT and JK_LB_LOCK_PESSIMISTIC have no functional relevance in the code, because all compares are always done to the constants themselves. You could also use 42 and 99 as the two values: jk_lb_worker.c:if (p-lblock == JK_LB_LOCK_PESSIMISTIC) jk_lb_worker.c:if (p-lblock == JK_LB_LOCK_PESSIMISTIC) jk_lb_worker.c:if (p-lblock == JK_LB_LOCK_PESSIMISTIC) jk_lb_worker.c:if (p-lblock == JK_LB_LOCK_PESSIMISTIC) jk_lb_worker.c:if (p-lblock == JK_LB_LOCK_PESSIMISTIC) jk_lb_worker.c:if (p-lblock == JK_LB_LOCK_PESSIMISTIC) jk_lb_worker.c:if (p-lblock == JK_LB_LOCK_PESSIMISTIC) jk_lb_worker.c:if (p-lblock == JK_LB_LOCK_PESSIMISTIC) jk_lb_worker.h:#define JK_LB_LOCK_DEFAULT (1) jk_lb_worker.h:#define JK_LB_LOCK_PESSIMISTIC (0) jk_status.c:jk_printf(s, td%s/td, lb-lblock == JK_LB_LOCK_DEFAULT ? JK_LB_LM_DEFAULT : JK_LB_LM_PESSIMISTIC); jk_util.c:return JK_LB_LOCK_DEFAULT; jk_util.c:return JK_LB_LOCK_DEFAULT; jk_util.c:return JK_LB_LOCK_DEFAULT; jk_util.c:return JK_LB_LOCK_PESSIMISTIC; jk_util.c:return JK_LB_LOCK_DEFAULT; What I don't like, is that the configuration value 0 in workers.properties is at the moment internally translated to 1 and vice versa. This might lead to confusion and is corrected by that part of my patch. I can only agree on the copy/paste typo for -return JK_LB_BYREQUESTS; +return JK_LB_LOCK_DEFAULT; That BTW would lead to the same behaviour because both defines are 0 so there are no functional difference. I know, no bug in the code, but I guess the proposed correction is what you really wanted to type ;) -- 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]
