Re: jk/cluster - intelligent systems load
If we goes back to the original thread and using Hyperic stuff in a servlet filter or whatever Tomcat extension ? Absolutely - a filter would be perfect and will work with any servlet engine. Jetty users will thanks Tomcat community :) There are some problems with making sure this doesn't leak out - i.e. an X-header inserted by mod_proxy and make sure it filters X-headers from the response. mod_proxy guru around ? Could it be usefull for jk, mod_proxy, mod_cluster ? Or a specific servlet should/could be provided for such collect purpose and it Will be called by remote at it's own rate ? That would work too, even better - a status servlet, which may provide additional data, like number of sessions, java memory, etc. Don't we have one already - dumping all jmx data ? Probably need to output data in an easier to parse format, and I guess mod_proxy configuration would be a bit tricky if you want to use multiple variables, but doable. a status servlet could be better, since it could also report informations about Tomcat engine, like number of ajp/http threads. A basic format for simple decoding of course :) BTW, since there is VMWare/SpringSourcer around, could the Hyperic stuff turned into ASL or BSD licence ? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
On 2/19/10 8:24 AM, Henri Gomez wrote: If we goes back to the original thread and using Hyperic stuff in a servlet filter or whatever Tomcat extension ? Absolutely - a filter would be perfect and will work with any servlet engine. Jetty users will thanks Tomcat community :) There are some problems with making sure this doesn't leak out - i.e. an X-header inserted by mod_proxy and make sure it filters X-headers from the response. mod_proxy guru around ? Not a mod_proxy guru, but filtering X-header from responses should be near trivial based on past experience with the proxy code. Nice discussion btw. This is a topic I've long been interested in. Bill - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Not a mod_proxy guru, but filtering X-header from responses should be near trivial based on past experience with the proxy code. Nice discussion btw. This is a topic I've long been interested in. You're not alone ;) Two options (not incompatible) to provide servlet engine information to back end (cluster system). - a filter add this information in a X-header, each Y requests, or Z seconds. - a servlet called explicitly by the back-end. There is the GPL licence 'problem' of the Hyperic lib which should be 'solved' isn't ? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
On 02/19/2010 05:06 PM, Henri Gomez wrote: Not a mod_proxy guru, but filtering X-header from responses should be near trivial based on past experience with the proxy code. There is the GPL licence 'problem' of the Hyperic lib which should be 'solved' isn't ? Tomcat Native already has some capabilities that can provide system not JVM options like CPU and Memory load on the box itself. For loadbalancing stuff this is all that is needed thought. Some of those are even displayed on status page when it's loaded in inside the Tomcat. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
On 02/19/2010 05:19 PM, Mladen Turk wrote: On 02/19/2010 05:06 PM, Henri Gomez wrote: Not a mod_proxy guru, but filtering X-header from responses should be near trivial based on past experience with the proxy code. There is the GPL licence 'problem' of the Hyperic lib which should be 'solved' isn't ? Tomcat Native already has some capabilities that can provide system not JVM options like CPU and Memory load on the box itself. For loadbalancing stuff this is all that is needed thought. Some of those are even displayed on status page when it's loaded in inside the Tomcat. Additionally JAVA6 provide stats information on the JVM. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
On Fri, Feb 19, 2010 at 8:51 AM, jean-frederic clere jfcl...@gmail.comwrote: On 02/19/2010 05:19 PM, Mladen Turk wrote: On 02/19/2010 05:06 PM, Henri Gomez wrote: Not a mod_proxy guru, but filtering X-header from responses should be near trivial based on past experience with the proxy code. There is the GPL licence 'problem' of the Hyperic lib which should be 'solved' isn't ? Tomcat Native already has some capabilities that can provide system not JVM options like CPU and Memory load on the box itself. For loadbalancing stuff this is all that is needed thought. Some of those are even displayed on status page when it's loaded in inside the Tomcat. Additionally JAVA6 provide stats information on the JVM. My preference would be to use the servlet - maybe enhance the JMXProxyServlet, which dumps all JMX information. The current format is relatively easy to parse - but can be made simpler, and you could add some parameter to select a subset of the mbeans. On Linux you can also grab a lot of stuff from /proc, and wrap it in a mbean or the servlet. Costin
Re: jk/cluster - intelligent systems load
Tomcat Native already has some capabilities that can provide system not JVM options like CPU and Memory load on the box itself. For loadbalancing stuff this is all that is needed thought. Some of those are even displayed on status page when it's loaded in inside the Tomcat. Additionally JAVA6 provide stats information on the JVM. It should but the IBM Java 6 didn't report it correctly for example ;( - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
My preference would be to use the servlet - maybe enhance the JMXProxyServlet, which dumps all JMX information. The current format is relatively easy to parse - but can be made simpler, and you could add some parameter to select a subset of the mbeans. JMXProxyServlet, I'll look at it. On Linux you can also grab a lot of stuff from /proc, and wrap it in a mbean or the servlet. Linux yes, but there is many others OS to support :( - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Tomcat Native already has some capabilities that can provide system not JVM options like CPU and Memory load on the box itself. For loadbalancing stuff this is all that is needed thought. Some of those are even displayed on status page when it's loaded in inside the Tomcat. Well it's a good candidate :) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
On 02/17/2010 10:46 PM, Costin Manolache wrote: On Wed, Feb 17, 2010 at 11:58 AM, Mladen Turk mt...@apache.org wrote: On 02/17/2010 07:37 PM, Costin Manolache wrote: On Wed, Feb 17, 2010 at 12:38 AM, Mladen Turkmt...@apache.org wrote: The reasons I suggest using SPDY as a replacement for AJP - and supporting SPDY I have nothing against SPDY and it really looks cool, but IMHO it's doesn't look and feel like the rest of RFC protocol specifications. If you can push those guys to create a well known RFC-like doc, I'm sure that overall internet community will benefit from it. SPDY is still in development - there is an open mailing list and quite a few proposals/changes/discussions. I would guess the end result will end up as a RFC-like. Feel free to join the mailing list and push or volunteer for anything :-) The implementations - chrome, mod_spdy are also open source and with ASF-like license. OTOH we are discussing this 'protocol thing' for years instead like you noticed we concentrate on the tasks we wish to do. Think if we start from the protocol side we will stay there (nowhere) for few more years (although SPDY might be even more then we need). I think what matters is having a working SPDY implementation in tomcat, inter-operable with chrome/mod_spdy/google. If we start with this we'll probably make more progress than by discussing protocols :-) Yep, I have noted that people are preparing an implementation for httpd so at some point it will just porting that code to TC. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
On Thu, Feb 18, 2010 at 12:00 AM, jean-frederic clere jfcl...@gmail.comwrote: On 02/17/2010 10:46 PM, Costin Manolache wrote: On Wed, Feb 17, 2010 at 11:58 AM, Mladen Turk mt...@apache.org wrote: On 02/17/2010 07:37 PM, Costin Manolache wrote: On Wed, Feb 17, 2010 at 12:38 AM, Mladen Turkmt...@apache.org wrote: The reasons I suggest using SPDY as a replacement for AJP - and supporting SPDY I have nothing against SPDY and it really looks cool, but IMHO it's doesn't look and feel like the rest of RFC protocol specifications. If you can push those guys to create a well known RFC-like doc, I'm sure that overall internet community will benefit from it. SPDY is still in development - there is an open mailing list and quite a few proposals/changes/discussions. I would guess the end result will end up as a RFC-like. Feel free to join the mailing list and push or volunteer for anything :-) The implementations - chrome, mod_spdy are also open source and with ASF-like license. OTOH we are discussing this 'protocol thing' for years instead like you noticed we concentrate on the tasks we wish to do. Think if we start from the protocol side we will stay there (nowhere) for few more years (although SPDY might be even more then we need). I think what matters is having a working SPDY implementation in tomcat, inter-operable with chrome/mod_spdy/google. If we start with this we'll probably make more progress than by discussing protocols :-) Yep, I have noted that people are preparing an implementation for httpd so at some point it will just porting that code to TC. http://code.google.com/p/mod-spdy/ Costin Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
If we goes back to the original thread and using Hyperic stuff in a servlet filter or whatever Tomcat extension ? Could it be usefull for jk, mod_proxy, mod_cluster ? Or a specific servlet should/could be provided for such collect purpose and it Will be called by remote at it's own rate ? 2010/2/18, Costin Manolache cos...@gmail.com: On Thu, Feb 18, 2010 at 12:00 AM, jean-frederic clere jfcl...@gmail.comwrote: On 02/17/2010 10:46 PM, Costin Manolache wrote: On Wed, Feb 17, 2010 at 11:58 AM, Mladen Turk mt...@apache.org wrote: On 02/17/2010 07:37 PM, Costin Manolache wrote: On Wed, Feb 17, 2010 at 12:38 AM, Mladen Turkmt...@apache.org wrote: The reasons I suggest using SPDY as a replacement for AJP - and supporting SPDY I have nothing against SPDY and it really looks cool, but IMHO it's doesn't look and feel like the rest of RFC protocol specifications. If you can push those guys to create a well known RFC-like doc, I'm sure that overall internet community will benefit from it. SPDY is still in development - there is an open mailing list and quite a few proposals/changes/discussions. I would guess the end result will end up as a RFC-like. Feel free to join the mailing list and push or volunteer for anything :-) The implementations - chrome, mod_spdy are also open source and with ASF-like license. OTOH we are discussing this 'protocol thing' for years instead like you noticed we concentrate on the tasks we wish to do. Think if we start from the protocol side we will stay there (nowhere) for few more years (although SPDY might be even more then we need). I think what matters is having a working SPDY implementation in tomcat, inter-operable with chrome/mod_spdy/google. If we start with this we'll probably make more progress than by discussing protocols :-) Yep, I have noted that people are preparing an implementation for httpd so at some point it will just porting that code to TC. http://code.google.com/p/mod-spdy/ Costin Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
On Thu, Feb 18, 2010 at 10:57 AM, Henri Gomez henri.go...@gmail.com wrote: If we goes back to the original thread and using Hyperic stuff in a servlet filter or whatever Tomcat extension ? Absolutely - a filter would be perfect and will work with any servlet engine. There are some problems with making sure this doesn't leak out - i.e. an X-header inserted by mod_proxy and make sure it filters X-headers from the response. Could it be usefull for jk, mod_proxy, mod_cluster ? Or a specific servlet should/could be provided for such collect purpose and it Will be called by remote at it's own rate ? That would work too, even better - a status servlet, which may provide additional data, like number of sessions, java memory, etc. Don't we have one already - dumping all jmx data ? Probably need to output data in an easier to parse format, and I guess mod_proxy configuration would be a bit tricky if you want to use multiple variables, but doable. Costin 2010/2/18, Costin Manolache cos...@gmail.com: On Thu, Feb 18, 2010 at 12:00 AM, jean-frederic clere jfcl...@gmail.comwrote: On 02/17/2010 10:46 PM, Costin Manolache wrote: On Wed, Feb 17, 2010 at 11:58 AM, Mladen Turk mt...@apache.org wrote: On 02/17/2010 07:37 PM, Costin Manolache wrote: On Wed, Feb 17, 2010 at 12:38 AM, Mladen Turkmt...@apache.org wrote: The reasons I suggest using SPDY as a replacement for AJP - and supporting SPDY I have nothing against SPDY and it really looks cool, but IMHO it's doesn't look and feel like the rest of RFC protocol specifications. If you can push those guys to create a well known RFC-like doc, I'm sure that overall internet community will benefit from it. SPDY is still in development - there is an open mailing list and quite a few proposals/changes/discussions. I would guess the end result will end up as a RFC-like. Feel free to join the mailing list and push or volunteer for anything :-) The implementations - chrome, mod_spdy are also open source and with ASF-like license. OTOH we are discussing this 'protocol thing' for years instead like you noticed we concentrate on the tasks we wish to do. Think if we start from the protocol side we will stay there (nowhere) for few more years (although SPDY might be even more then we need). I think what matters is having a working SPDY implementation in tomcat, inter-operable with chrome/mod_spdy/google. If we start with this we'll probably make more progress than by discussing protocols :-) Yep, I have noted that people are preparing an implementation for httpd so at some point it will just porting that code to TC. http://code.google.com/p/mod-spdy/ Costin Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
On 02/16/2010 06:57 PM, Costin Manolache wrote: I think the main driver for replacing ajp is the 2-directional protocols - and if we replace it, why invent a new protocol and not just adopt SPDY, which has all we need. Totally agree. Both JK and AJP originate from days when the single server behind web server was the common topology and when there was no async processing. Beside SPDY, which some ASF folks that made a significant contribution to the original HTTP specs consider as unperfect, there is BWTP proposal (http://bwtp.wikidot.com/) Extending exiting protocols or just doing a 'quick hacks' like I see with many projects trying to address those issues will not work in the long run. At the end you will be faced with the clean drawing board. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
On Wed, Feb 17, 2010 at 12:38 AM, Mladen Turk mt...@apache.org wrote: On 02/16/2010 06:57 PM, Costin Manolache wrote: I think the main driver for replacing ajp is the 2-directional protocols - and if we replace it, why invent a new protocol and not just adopt SPDY, which has all we need. Totally agree. Both JK and AJP originate from days when the single server behind web server was the common topology and when there was no async processing. Beside SPDY, which some ASF folks that made a significant contribution to the original HTTP specs consider as unperfect, there is BWTP proposal (http://bwtp.wikidot.com/) SPDY has quite a few problems - but it's still an improvement over AJP and adds 2-directional and mulitplexing to HTTP - which is what we need. The main problem with a protocol is getting enough critical mass to overcome it's problems - HTTP is not perfect either. The reasons I suggest using SPDY as a replacement for AJP - and supporting SPDY out-of-box in tomcat: - it does what we need - there is one browser supporting it - and likely to take advantage of it - probably there will be at least one large domain using it :-) - There is also a mod_spdy for apache, and I'm sure there will be more. Regarding problems, my list is not very big: - requirements for compression and SSL - we don't need this for apache-tomcat communication. But it's easy to extend or configure the protocol to skip it / negotiate. - right now they only want to do it over 443 ( i.e. use CONNECT method ) to make sure proxies won't get in the way. Apparently UPDATE doesn't work in some places. That's also something we can extend - and seems to be due more to the desire to get something deployed. - of course - the current next-protocol SSL extension is out of question for java - which has problems even with the SSL session ticket. We might be able to support it with APR/openssl. - some cosmetic issues - I would prefer protobufs or thrift instead of yet-another binary format, sending the url as a header seems strange, binary header could be smaller, the server push is also a bit more complex than it should be. I don't think any matters, working around http is much worse. - I'm waiting for the flow control to be finalized - but seems reasonable. Extending exiting protocols or just doing a 'quick hacks' like I see with many projects trying to address those issues will not work in the long run. At the end you will be faced with the clean drawing board. There is never a 'clean drawing board', or a perfect protocol. Any new protocol needs to be adopted and needs to deal with existing infrastructure - proxies, blocked ports, timeouts in NATs, etc. BWTP doesn't seem so much better - mostly cosmetics. It's also more focused as a websocket - not as a browser-proxy-server protocol. And the list of implementations and potential adoption matters a lot for protocols. ( BTW: I write this wearing my own hat, my work on tomcat-lite and spdy is on my own time, etc ) Costin Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
On 02/17/2010 07:37 PM, Costin Manolache wrote: On Wed, Feb 17, 2010 at 12:38 AM, Mladen Turkmt...@apache.org wrote: The reasons I suggest using SPDY as a replacement for AJP - and supporting SPDY I have nothing against SPDY and it really looks cool, but IMHO it's doesn't look and feel like the rest of RFC protocol specifications. If you can push those guys to create a well known RFC-like doc, I'm sure that overall internet community will benefit from it. OTOH we are discussing this 'protocol thing' for years instead like you noticed we concentrate on the tasks we wish to do. Think if we start from the protocol side we will stay there (nowhere) for few more years (although SPDY might be even more then we need). Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
On Wed, Feb 17, 2010 at 11:58 AM, Mladen Turk mt...@apache.org wrote: On 02/17/2010 07:37 PM, Costin Manolache wrote: On Wed, Feb 17, 2010 at 12:38 AM, Mladen Turkmt...@apache.org wrote: The reasons I suggest using SPDY as a replacement for AJP - and supporting SPDY I have nothing against SPDY and it really looks cool, but IMHO it's doesn't look and feel like the rest of RFC protocol specifications. If you can push those guys to create a well known RFC-like doc, I'm sure that overall internet community will benefit from it. SPDY is still in development - there is an open mailing list and quite a few proposals/changes/discussions. I would guess the end result will end up as a RFC-like. Feel free to join the mailing list and push or volunteer for anything :-) The implementations - chrome, mod_spdy are also open source and with ASF-like license. OTOH we are discussing this 'protocol thing' for years instead like you noticed we concentrate on the tasks we wish to do. Think if we start from the protocol side we will stay there (nowhere) for few more years (although SPDY might be even more then we need). I think what matters is having a working SPDY implementation in tomcat, inter-operable with chrome/mod_spdy/google. If we start with this we'll probably make more progress than by discussing protocols :-) Costin Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
On 16/02/2010 07:01, Mladen Turk wrote: On 02/16/2010 12:24 AM, Mark Thomas wrote: On 15/02/2010 21:52, Filip Hanik - Dev Lists wrote: why not just a servlet filter? +1. I was going to suggest the same thing. Why not reusing the clustering code for that. It would allow to pre-redirect the requests without doing the actual ping for undeployed applications or for the instances going down. Just having filter would be enough to get the info about the single node, but the highest latency in mod_jk comes from detecting the failed node not the busiest one. I don't see why the current set of valid cluster nodes could not be passed back via a header. That raises the interesting question of if a node goes down, which component will notice first? The proxy or the cluster? With long timeouts in the proxy, there is a good chance the cluster will notice quite some time earlier so there is a definite advantage to this. The other thing it potentially allows is the cluster to tell the proxy about which nodes are in the cluster, allowing a more dynamic configuration. Not sure I'd want to use that in production, but in dev that could be useful. All of this / some of this could make a great GSOC project. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
On 02/16/2010 09:56 AM, Mark Thomas wrote: I don't see why the current set of valid cluster nodes could not be passed back via a header. Exactly. That raises the interesting question of if a node goes down, which component will notice first? The proxy or the cluster? With long timeouts in the proxy, there is a good chance the cluster will notice quite some time earlier so there is a definite advantage to this. Both mod_jk and isapi_redirect have now watchdog logic that can ping backends on regular intervals without user intervetion so the latency will be around 60 seconds which is IMO acceptable for node maintenance. Httpd 2.3+ has mod_hartbeat and mod_watchdog so this can easily be ported to mod_proxy_ajp/http The other thing it potentially allows is the cluster to tell the proxy about which nodes are in the cluster, allowing a more dynamic configuration. Not sure I'd want to use that in production, but in dev that could be useful. Hmm, the zero conf is actually more desired in production then in dev environments since it allows single point of admin and no need for webserver reconfig. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
On 16/02/2010 09:08, Mladen Turk wrote: On 02/16/2010 09:56 AM, Mark Thomas wrote: The other thing it potentially allows is the cluster to tell the proxy about which nodes are in the cluster, allowing a more dynamic configuration. Not sure I'd want to use that in production, but in dev that could be useful. Hmm, the zero conf is actually more desired in production then in dev environments since it allows single point of admin and no need for webserver reconfig. Its just a personal opinion. I don't like any form of auto-configuration in production because I always feel I never quite know what it is doing or, more importantly, what it might do. If folks want to use it in production then there would obviously be nothing stopping them. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
On 02/16/2010 10:21 AM, Mark Thomas wrote: On 16/02/2010 09:08, Mladen Turk wrote: On 02/16/2010 09:56 AM, Mark Thomas wrote: The other thing it potentially allows is the cluster to tell the proxy about which nodes are in the cluster, allowing a more dynamic configuration. Not sure I'd want to use that in production, but in dev that could be useful. Hmm, the zero conf is actually more desired in production then in dev environments since it allows single point of admin and no need for webserver reconfig. Its just a personal opinion. I don't like any form of auto-configuration in production because I always feel I never quite know what it is doing or, more importantly, what it might do. Well it's zero conf inside web server only, so its conf is passed from Tomcat, and that is certainly something strictly defined inside .xml or via some manager app. There was attempt for creating AJP14 protocol, since the current one lacks some IPC capabilities with the limited packed size being the major problem. However I'd rather see mod_jk/isapi with http protocol then creating some AJP extensions or even completely new protocol. Network and processing speed changed a lot since 90's so now there's almost no performance difference between AJP and HTTP implementations. With some new HTTP proposals for connection reusing even that factor could be eliminated in the future. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
On Tue, Feb 16, 2010 at 1:38 AM, Mladen Turk mt...@apache.org wrote: On 02/16/2010 10:21 AM, Mark Thomas wrote: On 16/02/2010 09:08, Mladen Turk wrote: On 02/16/2010 09:56 AM, Mark Thomas wrote: The other thing it potentially allows is the cluster to tell the proxy about which nodes are in the cluster, allowing a more dynamic configuration. Not sure I'd want to use that in production, but in dev that could be useful. Hmm, the zero conf is actually more desired in production then in dev environments since it allows single point of admin and no need for webserver reconfig. Its just a personal opinion. I don't like any form of auto-configuration in production because I always feel I never quite know what it is doing or, more importantly, what it might do. Well it's zero conf inside web server only, so its conf is passed from Tomcat, and that is certainly something strictly defined inside .xml or via some manager app. There was attempt for creating AJP14 protocol, since the current one lacks some IPC capabilities with the limited packed size being the major problem. However I'd rather see mod_jk/isapi with http protocol then creating some AJP extensions or even completely new protocol. Network and processing speed changed a lot since 90's so now there's almost no performance difference between AJP and HTTP implementations. With some new HTTP proposals for connection reusing even that factor could be eliminated in the future. IMHO bi-directional communication is quite important - there are all kind of new protocols ( web socket, SPDY ) that requires it. You can have apache as a frontend for those protocols - but than you need AJP or mod_proxy to support it as well. I think the main driver for replacing ajp is the 2-directional protocols - and if we replace it, why invent a new protocol and not just adopt SPDY, which has all we need. There are some issues with SPDY - like the requirement to compress and do SSL, but we can easily tweak it. Regarding auto-conf , smarter load balancing and the other features enabled by 2-directional communication - in a large enough cluster they become quite important. Costin
Re: jk/cluster - intelligent systems load
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 ? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
On 02/15/2010 04:38 AM, Henri Gomez wrote: 2010/2/12 Mark Thomasma...@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? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
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 Thomasma...@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
Re: jk/cluster - intelligent systems load
On 02/16/2010 12:24 AM, Mark Thomas wrote: On 15/02/2010 21:52, Filip Hanik - Dev Lists wrote: why not just a servlet filter? +1. I was going to suggest the same thing. Why not reusing the clustering code for that. It would allow to pre-redirect the requests without doing the actual ping for undeployed applications or for the instances going down. Just having filter would be enough to get the info about the single node, but the highest latency in mod_jk comes from detecting the failed node not the busiest one. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: jk/cluster - intelligent systems load
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. 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. 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. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
