Re: Bug or Feature inside mod_jk loadbalancer algo?
Peter Rossbach wrote: Hey, I have a strange loadbalancer behaviour at a customer site with Apache 2/mod_jk 1.2.14, JVM 1.5, Tomcat 5.5.9 (cluster), (Suse 9.1) Hi guys, Peter you are correct about this... I found by myself too, that balancer is misbehaving in some cases. One of them is 'domain' model, where multiple workers should behave like one on the global scale, but still maintain internal load. The other is for worker-like mpm's when cachesize is lower then the ThreadsPerChild. I've been able to fix that (sort of), but I'm not happy with the fix. What would I suggest is that we gather all the 'use cases' and write down what the predicted results should be. I'll create a separate .txt file (that will later be part of loadbalancer howto) upon which we can enter the configuration and expected behavior. How that sounds? I'm moving this discussion to the tomcat-dev@, so that we have the trace of it. OK? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug or Feature inside mod_jk loadbalancer algo?
Sounds good to me. Wrote a spec before implementation is very helpfull :-) The domain case with sticky session and real clustered szenarios is not easy. Peter Mladen Turk schrieb: Peter Rossbach wrote: Hey, I have a strange loadbalancer behaviour at a customer site with Apache 2/mod_jk 1.2.14, JVM 1.5, Tomcat 5.5.9 (cluster), (Suse 9.1) Hi guys, Peter you are correct about this... I found by myself too, that balancer is misbehaving in some cases. One of them is 'domain' model, where multiple workers should behave like one on the global scale, but still maintain internal load. The other is for worker-like mpm's when cachesize is lower then the ThreadsPerChild. I've been able to fix that (sort of), but I'm not happy with the fix. What would I suggest is that we gather all the 'use cases' and write down what the predicted results should be. I'll create a separate .txt file (that will later be part of loadbalancer howto) upon which we can enter the configuration and expected behavior. How that sounds? I'm moving this discussion to the tomcat-dev@, so that we have the trace of it. OK? 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]
DO NOT REPLY [Bug 25886] - Feature: PersistenceManager less restrictive at createSession with maxActiveSessions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25886. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25886 Feature: PersistenceManager less restrictive at createSession with maxActiveSessions [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-05 08:51 --- Fixed. The check is gone, I don't see the point of enforcing the active session value with a persistent manager. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25886] - Feature: PersistenceManager less restrictive at createSession with maxActiveSessions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25886. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25886 Feature: PersistenceManager less restrictive at createSession with maxActiveSessions --- Additional Comments From [EMAIL PROTECTED] 2004-01-05 09:49 --- Good desicion ! Now we can remove the rejectedSession Property also thanx Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25886] - Feature: PersistenceManager less restrictive at createSession with maxActiveSessions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25886. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25886 Feature: PersistenceManager less restrictive at createSession with maxActiveSessions --- Additional Comments From [EMAIL PROTECTED] 2004-01-04 15:38 --- Created an attachment (id=9791) PersistenceManagerBase - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25886] - Feature: PersistenceManager less restrictive at createSession with maxActiveSessions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25886. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25886 Feature: PersistenceManager less restrictive at createSession with maxActiveSessions --- Additional Comments From [EMAIL PROTECTED] 2004-01-04 15:39 --- Created an attachment (id=9792) PersistenceManagerBaseTest - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug or feature?
Sorry for answering my own mail but I lost the thread and want to clarify some aspects with respect to Matts message. He wrote: --- This means that ALL roles can access this resource. When you specify *, you don't need to specify security-role below, but if you DO specify a role or roles, then it is necessary to define roles. At least, this is my impression from the specs. If you want your desired behavior, change role-name to use specialrole. --- Principally this sounds good and I'm aware of the solution but is this the specified behaviour? Again: what are security-role definitions good for? And again I'll refer to the spec - see below. Thomas Paradies wrote: Hi, I'm a little bit confused about the use of the security-role tag - generally and especially in Tomcat. The WebApp DTD refers for auth-constraint to this element commented as follows: ... The role-name used here must either correspond to the role-name of one of the security-role elements defined for this web application In TC the role-name in auth-constraint isn't verified against an corresponding security-role definition. (test: replace * by tomcat do not define a security-role) This is a MUST. , or be the specially reserved role-name * that is a compact syntax for indicating all roles in the web application. IMO this means that * is limited for indicating all roles in THE WEB APPLICATION and should not not do this for roles in other web applications even if the share the same realm. ... If no roles are defined, no user is allowed access to the portion of the web application described by the containing security-constraint... I understand this as a MUST. And no roles are defined relates in my eyes to the web application. Comments are welcome. I've tried to do this with Tomcat (4.1.16) but it didn't work as described. Tested with this web.xml (test.jsp also needed): ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app servlet servlet-nameRoleRef/servlet-name jsp-file/test.jsp/jsp-file /servlet servlet-mapping servlet-name RoleRef /servlet-name url-pattern /test /url-pattern /servlet-mapping security-constraint web-resource-collection web-resource-nameWebCollection/web-resource-name url-pattern/test/url-pattern /web-resource-collection auth-constraint role-name*/role-name /auth-constraint /security-constraint login-config auth-methodBASIC/auth-method realm-namedefault/realm-name /login-config !-- uncommenting security-role causes nothing -- security-role role-namespecialrole/role-name /security-role /web-app Only specialRole should have the permission to access the resource test.jsp, if uncommented no user should have this permission - but in Tomcat any role (e.g. tomcat, from global context) has in both cases the permission ... Is this wanted behaviour or is this a bug? Regards, Thomas Paradies -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Regards, Thomas Paradies -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Bug or feature?
Hi, I'm a little bit confused about the use of the security-role tag - generally and especially in Tomcat. The WebApp DTD refers for auth-constraint to this element commented as follows: ... The role-name used here must either correspond to the role-name of one of the security-role elements defined for this web application, or be the specially reserved role-name * that is a compact syntax for indicating all roles in the web application. ... If no roles are defined, no user is allowed access to the portion of the web application described by the containing security-constraint... I've tried to do this with Tomcat (4.1.16) but it didn't work as described. Tested with this web.xml (test.jsp also needed): ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app servlet servlet-nameRoleRef/servlet-name jsp-file/test.jsp/jsp-file /servlet servlet-mapping servlet-name RoleRef /servlet-name url-pattern /test /url-pattern /servlet-mapping security-constraint web-resource-collection web-resource-nameWebCollection/web-resource-name url-pattern/test/url-pattern /web-resource-collection auth-constraint role-name*/role-name /auth-constraint /security-constraint login-config auth-methodBASIC/auth-method realm-namedefault/realm-name /login-config !-- uncommenting security-role causes nothing -- security-role role-namespecialrole/role-name /security-role /web-app Only specialRole should have the permission to access the resource test.jsp, if uncommented no user should have this permission - but in Tomcat any role (e.g. tomcat, from global context) has in both cases the permission ... Is this wanted behaviour or is this a bug? Regards, Thomas Paradies -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Bug or feature?
On Friday, December 6, 2002, at 07:05 AM, Thomas Paradies wrote: Hi, I'm a little bit confused about the use of the security-role tag - generally and especially in Tomcat. The WebApp DTD refers for auth-constraint to this element commented as follows: ... The role-name used here must either correspond to the role-name of one of the security-role elements defined for this web application, or be the specially reserved role-name * that is a compact syntax for indicating all roles in the web application. ... If no roles are defined, no user is allowed access to the portion of the web application described by the containing security-constraint... I've tried to do this with Tomcat (4.1.16) but it didn't work as described. Tested with this web.xml (test.jsp also needed): ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app servlet servlet-nameRoleRef/servlet-name jsp-file/test.jsp/jsp-file /servlet servlet-mapping servlet-name RoleRef /servlet-name url-pattern /test /url-pattern /servlet-mapping security-constraint web-resource-collection web-resource-nameWebCollection/web-resource-name url-pattern/test/url-pattern /web-resource-collection auth-constraint role-name*/role-name /auth-constraint This means that ALL roles can access this resource. When you specify *, you don't need to specify security-role below, but if you DO specify a role or roles, then it is necessary to define roles. At least, this is my impression from the specs. If you want your desired behavior, change role-name to use specialrole. /security-constraint login-config auth-methodBASIC/auth-method realm-namedefault/realm-name /login-config !-- uncommenting security-role causes nothing -- security-role role-namespecialrole/role-name /security-role /web-app Only specialRole should have the permission to access the resource test.jsp, if uncommented no user should have this permission - but in Tomcat any role (e.g. tomcat, from global context) has in both cases the permission ... Is this wanted behaviour or is this a bug? Regards, Thomas Paradies -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
