Re: Feature request /Discussion: JK loadbalancer improvements for high load

2007-07-05 Thread Henri Gomez
Something we should also check is the CPU load of the Tomcat instance. May be it will be usefull also to let users/admin add their own counters in the load estimation. For example, if some admins considers we should base the load-balancing on HTTP requests or SQL access, and they have these count

Re: Feature request /Discussion: JK loadbalancer improvements for high load

2007-07-05 Thread jean-frederic clere
Henri Gomez wrote: Something we should also check is the CPU load of the Tomcat instance. May be it will be usefull also to let users/admin add their own counters in the load estimation. If you want to add this to Tomcat remeber that stuff needs a JNI module to collect information from the OS/

svn commit: r553410 - /tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/http/ServerCookie.java

2007-07-05 Thread jfclere
Author: jfclere Date: Thu Jul 5 01:13:06 2007 New Revision: 553410 URL: http://svn.apache.org/viewvc?view=rev&rev=553410 Log: Escape the " in the cookie value. Modified: tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/http/ServerCookie.java Modified: tomcat/tc6.0.x/trunk/java/org/apache/t

Re: Feature request /Discussion: JK loadbalancer improvements for high load

2007-07-05 Thread Henri Gomez
Well many beans are allready available : java.lang.Theading java.lang.MemoryPool I could see also some beans related to CPU load but using a Sun JVM (not on IBM). 2007/7/5, jean-frederic clere <[EMAIL PROTECTED]>: Henri Gomez wrote: > Something we should also check is the CPU load of the Tomca

Re: Feature request /Discussion: JK loadbalancer improvements for high load

2007-07-05 Thread Yefym Dmukh
Hi Rainer, seems we have still an issue in jvm config. we have not noticed the concurrent mode gc failures that led to tomcat overload and bad responses. 14896.148: [Full GC 14896.148: [CMS (concurrent mode failure): 1102956K->326641K(2359296K), 4.0684463 secs] 1280549K->326641K(3067136K), [CMS

Re: Feature request /Discussion: JK loadbalancer improvements for high load

2007-07-05 Thread Yefym Dmukh
Hi Rainer, seems we have still an issue in jvm config. we have not noticed the concurrent mode gc failures that led to tomcat overload and bad responses. 14896.148: [Full GC 14896.148: [CMS (concurrent mode failure): 1102956K->326641K(2359296K), 4.0684463 secs] 1280549K->326641K(3067136K), [CMS

Re: Feature request /Discussion: JK loadbalancer improvements for high load

2007-07-05 Thread Mladen Turk
Yefym Dmukh wrote: Actually the following was happening: the LB sends requests and gets the session sticky, continuously sending the upcoming requests to the same cluster node. At the certain period of time the JVM started the major garbage collection (full gc) and spent, mentioned above, 20

Re: Feature request /Discussion: JK loadbalancer improvements for high load

2007-07-05 Thread Mladen Turk
Yefym Dmukh wrote: Actually the following was happening: the LB sends requests and gets the session sticky, continuously sending the upcoming requests to the same cluster node. At the certain period of time the JVM started the major garbage collection (full gc) and spent, mentioned above, 20

Re: Feature request /Discussion: JK loadbalancer improvements for high load

2007-07-05 Thread Mladen Turk
Yefym Dmukh wrote: You have oxymoron here. With session stickiness you are willingly tear down the load balancer correctness because you don't wish/can have session replication. Generally you are right, but the ideal world is not the reality: we use apache my faces implementation of jsf where t

Re: Feature request /Discussion: JK loadbalancer improvements for high load

2007-07-05 Thread Yefym Dmukh
>You have oxymoron here. With session stickiness you are willingly >tear down the load balancer correctness because you don't wish/can >have session replication. >Even with the smartest LB and even with the two way communication >it's only possible to make that working in non session stickyness >to

svn commit: r553505 - /tomcat/container/branches/tc5.0.x/catalina/src/share/org/apache/naming/resources/ResourceCache.java

2007-07-05 Thread fhanik
Author: fhanik Date: Thu Jul 5 06:45:42 2007 New Revision: 553505 URL: http://svn.apache.org/viewvc?view=rev&rev=553505 Log: Backport fix for windows problem with Math.floor Modified: tomcat/container/branches/tc5.0.x/catalina/src/share/org/apache/naming/resources/ResourceCache.java Modifi

Re: Feature request /Discussion: JK loadbalancer improvements for high load

2007-07-05 Thread Yefym Dmukh
Mladen wrote: >This won't help much. The sticky session requests must be served >by the same node (group of nodes if using domain clustering), >and your requests will still be delayed by the JVM instance GC cycle >(It has to happen sometime, and you cannot depend on request >void intervals) The ma

Re: Feature request /Discussion: JK loadbalancer improvements for high load

2007-07-05 Thread Rainer Jung
OK, this culd make sense, i.e. heap nearly full on node1 failover to other cluster member node2 (replcation assumed) and trigger GC by System.gc() on node1. Interesting idea ... (for JK3 and beyond). Yefym Dmukh wrote: Mladen wrote: This won't help much. The sticky session requests must be se

Re: Feature request /Discussion: JK loadbalancer improvements for high load

2007-07-05 Thread Filip Hanik - Dev Lists
Question, why would you need GC,heap or CPU stats from the Tomcat machine at all? in most cases, none of these stats can predict response times. The best way would be to simply record a history of response times, and then mod_jk can have algorithms (maybe even pluggable) on how to use those s

Re: Feature request /Discussion: JK loadbalancer improvements for high load

2007-07-05 Thread Yefym Dmukh
>Question, why would you need GC,heap or CPU stats from the Tomcat >machine at all? >in most cases, none of these stats can predict response times. >The best way would be to simply record a history of response times, and >then mod_jk can have algorithms (maybe even pluggable) on how to use >thos

svn commit: r553628 - in /tomcat/sandbox/bayeux/java/org/apache/comet: bayeux/ json/

2007-07-05 Thread fhanik
Author: fhanik Date: Thu Jul 5 13:50:13 2007 New Revision: 553628 URL: http://svn.apache.org/viewvc?view=rev&rev=553628 Log: Added license headers Implemented a streaming parser for JSON reading, so that we can read data directly from the reader without having to parse it twice Added: tomca

svn commit: r553631 - in /tomcat/sandbox/bayeux: java/org/apache/comet/json/ReaderCharIterator.java test/ test/org/ test/org/apache/ test/org/apache/comet/ test/org/apache/comet/test/ test/org/apache/

2007-07-05 Thread fhanik
Author: fhanik Date: Thu Jul 5 13:55:07 2007 New Revision: 553631 URL: http://svn.apache.org/viewvc?view=rev&rev=553631 Log: Added test and fixed the streaming reader to work with multiple messages Added: tomcat/sandbox/bayeux/test/ tomcat/sandbox/bayeux/test/org/ tomcat/sandbox/baye

svn commit: r553634 - /tomcat/sandbox/bayeux/README.txt

2007-07-05 Thread fhanik
Author: fhanik Date: Thu Jul 5 14:08:31 2007 New Revision: 553634 URL: http://svn.apache.org/viewvc?view=rev&rev=553634 Log: some added readme notes Modified: tomcat/sandbox/bayeux/README.txt Modified: tomcat/sandbox/bayeux/README.txt URL: http://svn.apache.org/viewvc/tomcat/sandbox/bayeux

DO NOT REPLY [Bug 42822] New: - Entity resolution in JSP documents

2007-07-05 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

svn commit: r553700 - in /tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/http: AcceptLanguage.java BaseRequest.java Cookies.java MimeMap.java Parameters.java ServerCookie.java

2007-07-05 Thread markt
Author: markt Date: Thu Jul 5 19:36:32 2007 New Revision: 553700 URL: http://svn.apache.org/viewvc?view=rev&rev=553700 Log: o.a.t.util.http Tabs -> 8 spaces Fix compiler warnings No functional change Modified: tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/http/AcceptLanguage.java tomc

svn commit: r553716 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/CookieTools.java

2007-07-05 Thread markt
Author: markt Date: Thu Jul 5 20:31:04 2007 New Revision: 553716 URL: http://svn.apache.org/viewvc?view=rev&rev=553716 Log: Remove old util class that is no longer used. Removed: tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/CookieTools.java ---