On 15/02/2010 21:52, Filip Hanik - Dev Lists wrote: > On 02/15/2010 04:38 AM, Henri Gomez wrote: >> 2010/2/12 Mark Thomas<ma...@apache.org>: >> >>> On 12/02/2010 15:20, Henri Gomez wrote: >>> >>>> Hi to all, >>>> >>>> Some times ago, we discuss about mod_jk/cluster and more intelligent >>>> strategy to be use for the dispatching system. >>>> >>>> One point was to get system load informations about the various Tomcat >>>> instances involved in a cluster, to send request to the lowest loaded >>>> Tomcat. >>>> >>>> Hyperic Sigar, http://www.hyperic.com/products/sigar.html, seems to >>>> provide such informations for various OS. >>>> >>>> Could it be interesting to add such 'extension' to Tomcat, so it could >>>> be able to send back to jk/cluster so they could get the best >>>> decisions ? >>>> >>>> New commands could be added to AJP13, as done previously with >>>> cping/cpong, >>>> http://tomcat.apache.org/connectors-doc/ajp/ajpv13ext.html. >>>> >>>> What do you think about ? >>>> >>> I like the general idea. >>> >> Thanks >> >> >>> My personal favourite in terms of implementation is to pass the >>> information via response headers as it allows interoperability with the >>> widest possible range of front-end load balancers. The info can be >>> passed back with every request or only for requests to a particular URL. >>> >> Why not in response headers if it's discarded by the jk side. >> These informations shouldn't be send back to the browser (security >> concerns). >> >> >>> Then you get into how you measure load. I don't think that there will be >>> a one size fits all solution. I imagine that it would need to be fairly >>> easy for folks to implement their own load measurements. Using response >>> headers makes that simple to do providing we get the definition of that >>> header format right. >>> >> In response header it will allow both mod_jk (ajp), or mod_proxy >> (http) to get such decision. >> >> Question, how to add such informations in Tomcat ? >> Extension ? >> > why not just a servlet filter?
+1. I was going to suggest the same thing. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
