RE: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Thing is it's easier for end users to not have to mess around with third party builds if it can possibly be avoided, and it's the needs of the end users who are the most important, not the developers. It was the main reason why we tried to go beyond the concepts of jk/jk2 and co. Also, nowadays almost every server implementation requires some sort of dynamic context delivery. Ajp concept has a nice feature not being dependant on any external toolkits like for example mod_perl and php are, so it's a good candidate for inclusion inside the core distribution. The fact that the current module has to be built separately is a huge issue for the users of the module, making such a module a built in addition to proxy will make people's lives easier. Henri tried to see if there is a common interest to possibly make a mod_ajp part of the core distribution. Think that discussion is leading to use the mod_proxy like a container for ajp protocol, that could be fine, but something like mod_proxy concept we already have in the jk2, called modular protocol. The main reason why we are trying to make a successor for jk/jk2 is simplicity and static set of requirements. Trying again to use the something would lead to the same problems thought. I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I think it would be better that we develop the module inside j-t-c tree, and kindly ask the guys to see if there is a possibility to include it in the core distribution, when we reach some level of stability. MT. smime.p7s Description: S/MIME cryptographic signature
Re: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: Graham Leggett wrote: Thing is it's easier for end users to not have to mess around with third party builds if it can possibly be avoided, and it's the needs of the end users who are the most important, not the developers. It was the main reason why we tried to go beyond the concepts of jk/jk2 and co. Also, nowadays almost every server implementation requires some sort of dynamic context delivery. Ajp concept has a nice feature not being dependant on any external toolkits like for example mod_perl and php are, so it's a good candidate for inclusion inside the core distribution. The fact that the current module has to be built separately is a huge issue for the users of the module, making such a module a built in addition to proxy will make people's lives easier. Henri tried to see if there is a common interest to possibly make a mod_ajp part of the core distribution. Think that discussion is leading to use the mod_proxy like a container for ajp protocol, that could be fine, but something like mod_proxy concept we already have in the jk2, called modular protocol. The main reason why we are trying to make a successor for jk/jk2 is simplicity and static set of requirements. Trying again to use the something would lead to the same problems thought. I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I think it would be better that we develop the module inside j-t-c tree, and kindly ask the guys to see if there is a possibility to include it in the core distribution, when we reach some level of stability. Good resume Mladen. Many nice things was discussed on this thread : - adding load-balancing/fault-tolerant support for mod_proxy. A nice features to provide to mod_proxy users, and as such not dedicated to tomcat users. So it could (should ?) be an extension developped by mod_proxy and HTTPD team. And if they could make the lb/ft algorythm easy configurable (ie handling JSESSION_ID), it will be perfectly feeted for users who want to use the HTTP/1.1 connector of their servlet engines (tomcat of course, but it could be others like jetty). - adding ajp_proxy support to mod_proxy. With that mod_proxy could relay request to ajp:// pseudo URL. JK/JK2 developpers should learn how to make a mod_proxy sub module, and play for example with brigade :) In such case, there is no direct lb/ft support, so it will depend on the previously mentionned support in mod_proxy itself. - creating a mod_ajp which will mimics mod_proxy features but with jk/jk2 features in mind. - our actual lb/ft support (which should be more simple or better documented). - at a later time, dynamic topology (tomcat clusters state changes, application state in each tomcat, update of tomcat load level...) I'm more than pleased to read that httpd members see mod_ajp/ajp_proxy as something to be included in HTTPD tree, now or may be after an incubation period in the jakarta-tomcat-connector sub project. Of course it will make the couple Apache/Tomcat ready to use and as such easier for some of us to 'sell' to their clients and IT managers. So what should we do now ? - An initial step seems to extract all ajp functionnalities from jk/jk2, into an ajp library (or some c/h files). Basic AJP functions should use APR for all OS/NET/MEMORY operations and there is some code ready for this in jk2. - int ajp_open_connection(ajp_connection_t **, char *, apr_port_t) - int ajp_close_connection(ajp_connection_t *) - int ajp_send_request_headers(ajp_connection_t *, apr_table_entry_t *); - int ajp_send_request_datas(ajp_connection_t *, apr_pool_t *) - int ajp_receive_reply(ajp_connection_t *, apr_pool_t *) All of this should be using only APR objects like apr_socket_t, apr_sockaddr_t, apr_table_entry_t (headers), apr_pool_t... Next advanced AJP functions will forward a complete Apache 2 request to a tomcat. Many objects part of the Ap2 request are allready available in the Basic AJP functions, ie for headers the apr_table_entry_t... We could then work on a mod_ajp prototype, using only env var for example, to redirect a request to the correct named ajp instance (don't speak about worker). With such simple prototype we could see which hooks should be implemented, probably only ap_hook_handler/ap_hook_post_config. Actually jk 1.2.x may implements too many hooks, I didn't see any Apache 2 modules with all of these : ap_hook_handler(jk_handler,NULL,NULL,APR_HOOK_MIDDLE);
Re: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I rewrote proxy, so I know - proxy has the exact same conceptual approach and is used for the exact same purposes. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Mladen Turk wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I rewrote proxy, so I know - proxy has the exact same conceptual approach and is used for the exact same purposes. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Make sense of course. And if proxy_loadbalance and proxy_sticky are somewhat configurable, it will be to the benefits all of Apache 2 users, dependless HTTP/FTP/AJP. BTW, could we expect to be able to use in proxy_ajp URL like ajp://VIRTUALNAME, where VIRTUALNAME could be the name of an AJP cluster backend ? Also could we expect the handling of failure via mod_proxy + proxy_xxx , ie: when a tomcat respond 503 or 400, to be able to switch to another tomcat in the cluster. It's a mandatory feature for now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: BTW, could we expect to be able to use in proxy_ajp URL like ajp://VIRTUALNAME, where VIRTUALNAME could be the name of an AJP cluster backend ? That would be up to proxy_ajp to decide, so yes. What happens is that when the config says ProxyPass /myApp ajp://VIRTUALNAME and the user requests the URL /myApp/index.jsp, proxy will give proxy_ajp an URL that looks like this: ajp://VIRTUALNAME/index.jsp It's up to proxy_ajp to understand what that means. Also could we expect the handling of failure via mod_proxy + proxy_xxx , ie: when a tomcat respond 503 or 400, to be able to switch to another tomcat in the cluster. It's a mandatory feature for now. Proxy already loops around and tries again on connection failure to a different server in the backend. If proxy cannot handle a 503 or a 400, then it can be made to handle it - again it's a feature that would be really useful regardless of the protocol. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. I'm sure that the 'normalization' would lead to nowhere. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. HTTP is a statles protocol, and our concept is to have a constant connection pool to the well known application server. So, unlike HTTP protocol we are embedding the remote application server, and it just happens that we are doing it using the same TCP/IP protocol for that. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. Quite contraty, this is the main reason. We already have jk2 that can be used even for proxying HTTP requests. Are you wiling to write the http protocol for mod_jk2? The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. Again, application server != http server. The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Agreed, pehaps some day they will convolve to the single module, but right now I don't see the point for it, especialy when the mod_proxy is well established module. Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Well, that's how you see it. IMO trying again to squize the apache2-Tomcat module inside some already present solution would again lead to nowhere, and finally rise the questions like we are rising today. MT. smime.p7s Description: S/MIME cryptographic signature
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Mladen Turk wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I rewrote proxy, so I know - proxy has the exact same conceptual approach and is used for the exact same purposes. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. I see in ap_proxy_http_handler() that DECLINED allows to try another. Is there somewhere an example of a configuration using it? The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. I'm sure that the 'normalization' would lead to nowhere. I don't follow - what does normalisation would lead to nowhere mean? HTTP is a statles protocol, and our concept is to have a constant connection pool to the well known application server. So, unlike HTTP protocol we are embedding the remote application server, and it just happens that we are doing it using the same TCP/IP protocol for that. You are missing the purpose of mod_proxy. It is not an HTTP proxy only, but a general protocol proxy that can support both stateless and stateful backends. Proxy supports HTTP keepalives (via a mechanism that can be extended into a full pool), and it supports FTP (a stateful protocol). There is no reason why proxy could not support another stateful protocol like AJP. If httpd is to support another backend protocol, then the proxy frameowrk is the place to do it. Quite contraty, this is the main reason. We already have jk2 that can be used even for proxying HTTP requests. Are you wiling to write the http protocol for mod_jk2? Considering that httpd already has a framework to connect to various backend protocols (proxy and friends), and already has an established syntax within httpd, I don't see any point in replacing it with another external module like the existing mod_jk2. Are you willing to write the ftp module for mod_jk2? Again, application server != http server. Of course an http server is an application server. Agreed, pehaps some day they will convolve to the single module, but right now I don't see the point for it, especialy when the mod_proxy is well established module. I think there is a fundamental misunderstanding as to the way proxy works. mod_proxy is a framework - the module is not useful on it's own without helper modules plugged into the back of it. Right now, there are helper modules to support HTTP/1.1, FTP and HTTP/1.1's CONNECT method. mod_proxy currently handles the connection to the backend, it then passes this connection to the protocol handler module for completion. This connection handling can easily be pulled out into a load balancing module, allowing connections to the backend to be reused for HTTP keepalives, FTP session continuation and a connection pool for AJP, or a proxy_sticky module, that is able to ensure the same requests go to the same server. The bottom line is that httpd has an established framework for supporting backend application server protocols like HTTP, FTP, and now AJP. So far I have seen no technical justification whatsoever for putting an AJP protocol module outside of this framework. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: Graham Leggett wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. I'm sure that the 'normalization' would lead to nowhere. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. HTTP is a statles protocol, and our concept is to have a constant connection pool to the well known application server. So, unlike HTTP protocol we are embedding the remote application server, and it just happens that we are doing it using the same TCP/IP protocol for that. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. Quite contraty, this is the main reason. We already have jk2 that can be used even for proxying HTTP requests. Are you wiling to write the http protocol for mod_jk2? The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. Again, application server != http server. The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Agreed, pehaps some day they will convolve to the single module, but right now I don't see the point for it, especialy when the mod_proxy is well established module. Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Well, that's how you see it. IMO trying again to squize the apache2-Tomcat module inside some already present solution would again lead to nowhere, and finally rise the questions like we are rising today. Not sure since mod_proxy will associate to a ajp://VIRTUALNAME, and in such case it's up to proxy_ajp to decide to : - keep the socket open - handle a pool of socket - fall back to another AJP instance in the cluster. So I think it could be done - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
jean-frederic clere wrote: I see in ap_proxy_http_handler() that DECLINED allows to try another. Is there somewhere an example of a configuration using it? ap_proxy_http_handler() is found in mod_proxy_http, which is the helper module that handles the HTTP protocol in the proxy framework. You will find a corresponding ap_proxy_ftp_handler() inside mod_proxy_ftp. mod_proxy tries each handler in turn until one of the handlers says I can serve this URL, I'll take it. ap_proxy_http_handler() will return DECLINED if the URL of the backend is not http: or https:, allowing mod_proxy_ftp, mod_proxy_connect or a potential mod_proxy_ajp to have a go at trying serve the URL. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
RE: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Graham Leggett wrote: Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Well, that's how you see it. IMO trying again to squize the apache2-Tomcat module inside some already present solution would again lead to nowhere, and finally rise the questions like we are rising today. Not sure since mod_proxy will associate to a ajp://VIRTUALNAME, and in such case it's up to proxy_ajp to decide to : I think that we forked from jk/jk2 to be able to write from the scratch the module that will do exactly _one_ and _only_one_ thing; and that is effectively communicate with TC server using ajp13+ protocol. So, my question is. Why do we need again some container to accomplish that? There are just too many compromises that we need to take if building proxy_ajp, and I thought that we wish no compromises at all. If we don' t build a module that will do exactly what it's meant to be doing, well... Same story again, and I don't understand why one would wish to do that? If someone wishes to make a proxy_ajp I don't have a problem with that, quite opposite, but I still wish to write (like initially said) the module that will only and only communicate to application server cluster, nothing less, nothing more. We already have a bunch of modules that can use WTF protocol you wish, but no one can configure or use it without reading 500 page book that doesn't even exists. - keep the socket open - handle a pool of socket - fall back to another AJP instance in the cluster. So I think it could be done I'm sure it can, but like I said, you can mimic the mod_proxy inside jk2. It also can be done :) MT. smime.p7s Description: S/MIME cryptographic signature
Re: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: I think that we forked from jk/jk2 to be able to write from the scratch the module that will do exactly _one_ and _only_one_ thing; and that is effectively communicate with TC server using ajp13+ protocol. So, my question is. Why do we need again some container to accomplish that? Because the container already gives you an established configuration method, a standard set of documentation, and a standard expectation from end users on how it should work. Remember the end goal of the exercise is to produce software which solves a real world need of end users. One of the biggest real world end user needs is something simple and straightforward that lets me get the job done with the least amount of time wasted messing around. As a user, I would ask why is the config for mod_jk different for mod_proxy?, and in fact as a user that's the exact reason I don't bother to use mod_jk. The easiest way to make the config method for mod_proxy and mod_jk the same is to implement proxy_ajp. There are just too many compromises that we need to take if building proxy_ajp, and I thought that we wish no compromises at all. Compromises like what? I see no reason why every single feature of mod_jk cannot be implemented in a proxy_ajp, or with the assitance of other potential modules with general application like proxy_loadbalancer. If we don' t build a module that will do exactly what it's meant to be doing, well... Same story again, and I don't understand why one would wish to do that? If someone wishes to make a proxy_ajp I don't have a problem with that, quite opposite, but I still wish to write (like initially said) the module that will only and only communicate to application server cluster, nothing less, nothing more. This is the precise goal of the proxy framework. mod_proxy_http communicates with an HTTP server, nothing less, nothing more. It doesn't cache, it doesn't do anything - that's the job of other httpd modules like mod_dir, mod_cache, etc. mod_proxy_ftp communicates with an FTP server, nothing less, nothing more. mod_proxy_ajp would communicate via AJP. Nothing less, nothing more. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
RE: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: So, my question is. Why do we need again some container to accomplish that? Because the container already gives you an established configuration method, a standard set of documentation, and a standard expectation from end users on how it should work. That's all OK. Look at the mail archive and you will see that this is exactly the 'look and feel' that we wish to achieve. Compromises like what? AjpWorker and AjpBalancer for example, or do we need to mimic that inside the existing configuration directives? Well the, AjpWorker can be mapped to ProxyRemote if you change it to ProxyRemote. See my point? There is also a lot of extra params that we'll need to set for each particular worker or Remote. If you are will to support something like that, then we can speak on. I see no reason why every single feature of mod_jk cannot be implemented in a proxy_ajp, or with the assitance of other potential modules with general application like proxy_loadbalancer. Me neither. I really see no reason for that, except that we don't have neither proxy_ajp nor proxy_loadbalancer. I also see no reason why the mod_proxy functionally cannot be implemented in mod_jk2 :). If someone wishes to make a proxy_ajp I don't have a problem with that, quite opposite, but I still wish to write (like initially said) the module that will only and only communicate to application server cluster, nothing less, nothing more. This is the precise goal of the proxy framework. Look, if others on the tomcat-dev are willing to write the proxy_ajp and proxy_loadbalancer, then OK. After all, I'm Borg, I will adapt :). I personally don't like the idea, and still think that we should first make something workable outside the Apache2 tree, at least for the reason to be able to make a release without waiting for the rest of the guys. Would it be possible to copy the entire mod_proxy inside j-t-c tree and then later merge it with the httpd tree when we reach some version 1.0? Regards, MT. smime.p7s Description: S/MIME cryptographic signature
Re: Invitation to HTTPD commiters in tomcat-dev
One thing missing - the proposal to actually just use mod_proxy, with enhancements for load balancing, and with http as protocol ( i.e. drop Ajp ). That would be a real simplification on both sides ! The tiny performance benefit of a binary protocol is really not worth it. The 'http parsing' part is very small anyway. Most other problems can be solved with mod_proxy - including passing all auth headers and informations about original request in special headers, load balancing with all the flavors, etc. ( and security issues with the custom headers can be resolved as well ). I agree with Mladen that plugable protocol proved to be unnecesary, and it would be a bad idea for mod_proxy. Costin Henri Gomez wrote: Mladen Turk wrote: Graham Leggett wrote: Thing is it's easier for end users to not have to mess around with third party builds if it can possibly be avoided, and it's the needs of the end users who are the most important, not the developers. It was the main reason why we tried to go beyond the concepts of jk/jk2 and co. Also, nowadays almost every server implementation requires some sort of dynamic context delivery. Ajp concept has a nice feature not being dependant on any external toolkits like for example mod_perl and php are, so it's a good candidate for inclusion inside the core distribution. The fact that the current module has to be built separately is a huge issue for the users of the module, making such a module a built in addition to proxy will make people's lives easier. Henri tried to see if there is a common interest to possibly make a mod_ajp part of the core distribution. Think that discussion is leading to use the mod_proxy like a container for ajp protocol, that could be fine, but something like mod_proxy concept we already have in the jk2, called modular protocol. The main reason why we are trying to make a successor for jk/jk2 is simplicity and static set of requirements. Trying again to use the something would lead to the same problems thought. I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I think it would be better that we develop the module inside j-t-c tree, and kindly ask the guys to see if there is a possibility to include it in the core distribution, when we reach some level of stability. Good resume Mladen. Many nice things was discussed on this thread : - adding load-balancing/fault-tolerant support for mod_proxy. A nice features to provide to mod_proxy users, and as such not dedicated to tomcat users. So it could (should ?) be an extension developped by mod_proxy and HTTPD team. And if they could make the lb/ft algorythm easy configurable (ie handling JSESSION_ID), it will be perfectly feeted for users who want to use the HTTP/1.1 connector of their servlet engines (tomcat of course, but it could be others like jetty). - adding ajp_proxy support to mod_proxy. With that mod_proxy could relay request to ajp:// pseudo URL. JK/JK2 developpers should learn how to make a mod_proxy sub module, and play for example with brigade :) In such case, there is no direct lb/ft support, so it will depend on the previously mentionned support in mod_proxy itself. - creating a mod_ajp which will mimics mod_proxy features but with jk/jk2 features in mind. - our actual lb/ft support (which should be more simple or better documented). - at a later time, dynamic topology (tomcat clusters state changes, application state in each tomcat, update of tomcat load level...) I'm more than pleased to read that httpd members see mod_ajp/ajp_proxy as something to be included in HTTPD tree, now or may be after an incubation period in the jakarta-tomcat-connector sub project. Of course it will make the couple Apache/Tomcat ready to use and as such easier for some of us to 'sell' to their clients and IT managers. So what should we do now ? - An initial step seems to extract all ajp functionnalities from jk/jk2, into an ajp library (or some c/h files). Basic AJP functions should use APR for all OS/NET/MEMORY operations and there is some code ready for this in jk2. - int ajp_open_connection(ajp_connection_t **, char *, apr_port_t) - int ajp_close_connection(ajp_connection_t *) - int ajp_send_request_headers(ajp_connection_t *, apr_table_entry_t *); - int ajp_send_request_datas(ajp_connection_t *, apr_pool_t *) - int ajp_receive_reply(ajp_connection_t *, apr_pool_t *) All of this should be using only APR objects like apr_socket_t, apr_sockaddr_t, apr_table_entry_t (headers),
Re: Invitation to HTTPD commiters in tomcat-dev
- Original Message - From: Mladen Turk [EMAIL PROTECTED] I also see no reason why the mod_proxy functionally cannot be implemented in mod_jk2 :). yes, but it is rocket science to actually get jk2 compiled and configured and to work properly. mod_proxy is part of the core, and takes about 5 seconds to setup. That is the biggest difference the current user base is experiencing today. I've been on three commercial projects where mod_jk2 has been dropped and replaced with mod_proxy, (and not on my recommendation). That alone speaks for itself. If the successor of jk2 can be as easy to configure and setup with apache, then go for it. Otherwise I humble suggestion would be to start looking that direction. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Mladen Turk wrote: AjpWorker and AjpBalancer for example, or do we need to mimic that inside the existing configuration directives? Well the, AjpWorker can be mapped to ProxyRemote if you change it to ProxyRemote. See my point? AjpBalancer could be applied to a theoretical proxy_balancer module (all modules can define their own config parameters, even the helper modules, the only guideline is that the config directives are named to give some indication of the scope they're valid for, so instead of a directive called Fred which doesn't mean anything to anybody, it should be ProxyAjpFred). What does AjpWorker do? (Is there docs for mod_jk anywhere, when I last looked I could not find any). There is also a lot of extra params that we'll need to set for each particular worker or Remote. If you are will to support something like that, then we can speak on. Quite willing - the extra params can be defined as valid for the proxy_ajp module only, or extra general parameters can be added to the proxy framework. The idea is that if some feature has general application to all the modules (such as load balancing) then the change should be made to proxy and be applied system wide. Me neither. I really see no reason for that, except that we don't have neither proxy_ajp nor proxy_loadbalancer. I also see no reason why the mod_proxy functionally cannot be implemented in mod_jk2 :). Because of end user expectation. mod_proxy is currently the shipped with Apache option for backend protocol support. If suddenly mod_proxy and friends were turfed out and replaced with an entirely different module and different set of directives, people's reaction would be huh?. Look, if others on the tomcat-dev are willing to write the proxy_ajp and proxy_loadbalancer, then OK. After all, I'm Borg, I will adapt :). I personally don't like the idea, and still think that we should first make something workable outside the Apache2 tree, at least for the reason to be able to make a release without waiting for the rest of the guys. Would it be possible to copy the entire mod_proxy inside j-t-c tree and then later merge it with the httpd tree when we reach some version 1.0? You could do that - although if you make changes to mod_proxy itself (which you very likely will have to do to support some of the stuff, like the adding of new hooks, etc) it would be best if these were posted as they happened to the [EMAIL PROTECTED] list, then they could be applied to httpd v2.1-dev, with potential backports going to v2.0. Doing this in bite sized pieces as needed would be a lot easier to review than a single big merge at the end, although keeping a local copy for yourselves to try things out first will also make your lives easier. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Costin Manolache wrote: One thing missing - the proposal to actually just use mod_proxy, with enhancements for load balancing, and with http as protocol ( i.e. drop Ajp ). That would be a real simplification on both sides ! I also find HTTP to be more than adequate in most cases, but if there is a need for AJP and people are going to use it then I don't see why people can't build and contribute to an ajp module. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Mladen Turk wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Ok, I was wrong. Multiple protocol support is sometimes usefull :-), http and ftp are a good example of that. It wasn't in mod_jk. But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info - if we are not happy with the performance and we need a small boost, we could also add ajp. Costin Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I rewrote proxy, so I know - proxy has the exact same conceptual approach and is used for the exact same purposes. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Costin Manolache wrote: But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info - if we are not happy with the performance and we need a small boost, we could also add ajp. I think this is a good idea. Solve the general load balancer case first, then you will soon see whether HTTP works for everybody, or whether there is still a need for AJP. If there is a need, then someone will develop the AJP part of the module, but as the AJP module need not cocern itself with load balancing (that function being handled for it) it will be a far simpler module all round. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Costin Manolache wrote: But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info - if we are not happy with the performance and we need a small boost, we could also add ajp. I think this is a good idea. Solve the general load balancer case first, then you will soon see whether HTTP works for everybody, or whether there is still a need for AJP. If there is a need, then someone will develop the AJP part of the module, but as the AJP module need not cocern itself with load balancing (that function being handled for it) it will be a far simpler module all round. Well we have a stable jk 1.2.6 to be released by the end of the week. So next step should be to add LB functionalities (with sticky JSSESSION support) in mod_proxy = Graham ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Graham Leggett wrote: Costin Manolache wrote: But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info - if we are not happy with the performance and we need a small boost, we could also add ajp. I think this is a good idea. Solve the general load balancer case first, then you will soon see whether HTTP works for everybody, or whether there is still a need for AJP. If there is a need, then someone will develop the AJP part of the module, but as the AJP module need not cocern itself with load balancing (that function being handled for it) it will be a far simpler module all round. Well we have a stable jk 1.2.6 to be released by the end of the week. So next step should be to add LB functionalities (with sticky JSSESSION support) in mod_proxy = Graham ? I have tried the following in httpd.conf: +++ Location /examples/ ProxyPass http://pgtr0327.mch.fsc.net:8080/examples/ ProxyPassReverse http://pgtr0327.mch.fsc.net:8080/examples/ /Location +++ pgtr0327.mch.fsc.net:8080 is a normal tomcat and something so simple covers already some needs. Adding load balancing means that we have to define several Tomcats (only changing host and/or port) and use JSESSIONID to find the right Tomcat when getting a request in httpd. This could be done in a modified proxy_http.c Cheers Jean-Frederic - 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]
Re: Invitation to HTTPD commiters in tomcat-dev
But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info yes, this is what alot of users want Filip - Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 9:27 AM Subject: Re: Invitation to HTTPD commiters in tomcat-dev Graham Leggett wrote: Mladen Turk wrote: I don't think that it is necessary for a mod_ajp to be included inside the mod_proxy, although they are sharing some common concepts. I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd. Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this. Ok, I was wrong. Multiple protocol support is sometimes usefull :-), http and ftp are a good example of that. It wasn't in mod_jk. But I still think we should start with using mod_proxy with http protocol, and add the missing load balancing and extra info - if we are not happy with the performance and we need a small boost, we could also add ajp. Costin Consistency is very important. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP. I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat. The purpose of mod_ajp is to communicate with the (one or more of them in a cluster) application servers using ajp13+ protocol; simple as that. Proxy module has a conceptually different approach, and it is meant to be used for different purposes. I rewrote proxy, so I know - proxy has the exact same conceptual approach and is used for the exact same purposes. Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol. The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol. Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point. Regards, Graham -- - 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]
RE: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: So next step should be to add LB functionalities (with sticky JSSESSION support) in mod_proxy = Graham ? There is also a question of development cycle. Are we gonna develop sending patches or what... Suggestions? MT. smime.p7s Description: S/MIME cryptographic signature
Re: Invitation to HTTPD commiters in tomcat-dev
Nick Kew wrote: On Tue, 20 Jul 2004, Henri Gomez wrote: We're discussing on tomcat-dev about a new Apache to Tomcat Apache 2.x module. We'd like to see some of the core HTTPD developpers joins the discussion about the post JK/JK2 module. As a startingpoint, how about telling us what tomcat needs that mod_proxy and friends don't provide? In mod_jk/jk2, there is support for load-balancing and fault-tolerance and it's a key feature. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Nick Kew wrote: On Tue, 20 Jul 2004, Henri Gomez wrote: [ chopped tomcat-dev because that bounces my mail ] As a startingpoint, how about telling us what tomcat needs that mod_proxy and friends don't provide? In mod_jk/jk2, there is support for load-balancing and fault-tolerance and it's a key feature. Good start. I'm guessing you're ahead of me here, and your reason for posting to [EMAIL PROTECTED] is that you can see that implementing these capabilities will be of general interest to more than just tomcat users? Back to tomcat-dev + httpd-dev. Well this kind of features will be usefull for more than just Tomcat users of course. Our main interest in inviting httpd-dev members to tomcat-dev list is to see if common interest could be shared and of course take recommandations for the jk/jk2 successor. My gut feeling would be to keep this properly modular. Let mod_proxy be the core of it, and implement load-balancing and fault-tolerance in additional modules. As a matter of fact, one of my wishlist-projects is a connection-pooling module for backend HTTP connections in a proxy. That might actually be the same as your project. And what about using AJP/1.3 instead of HTTP for connection to tomcat ?) In fact mod_proxy could be a good starting point for learning how relying request from Apache 2.x to Tomcat for what we called actually mod_ajp, to avoid confusion with jk/jk2. But : - If you add load-balancing/fault-tolerance and AJP 1.3 support in mod_proxy you'll have about 99% of the current functionalities of jk 1.2.x. We discussed also the need for some dynamic mapping and topology discovery/update (between Apache and Tomcats Clusters). And in fine, we like to have some JMX like functionnalities in Apache 2, in our case CMX for C Management Extension, a way to update Apache 2.x configuration while the server is running... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: And what about using AJP/1.3 instead of HTTP for connection to tomcat ?) In all my deployments of tomcat I have never seen the point of a custom protocol that did exactly what HTTP does, so all my tomcat deployments are all HTTP, with a simple mod_proxy frontend. Even the get Apache to server static content feature wasn't enough of a drawcard, as proper HTTP cache handling and a suitable cache solved this problem. It was far more important for me to arrange the web application as a self contained unit - I would rather be more tidy with an install at the expense of a slightly higher load, than sacrifice a clean install to save some cycles. - If you add load-balancing/fault-tolerance and AJP 1.3 support in mod_proxy you'll have about 99% of the current functionalities of jk 1.2.x. We discussed also the need for some dynamic mapping and topology discovery/update (between Apache and Tomcats Clusters). Proxy has a placeholder in it that says put the code to make decision about load balancing etc here - all that is needed is a hook and a module proxy_loadbalancing.c to make it happen. And in fine, we like to have some JMX like functionnalities in Apache 2, in our case CMX for C Management Extension, a way to update Apache 2.x configuration while the server is running... This is possibly a whole separate project in itself. I have been meaning to work on a get-apache-config-out-of-ldap extension for a while, what it really should be is get apache config out of wherever, but this should be an Apache wide thing, not limited to a single module or technology. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Henri Gomez wrote: And what about using AJP/1.3 instead of HTTP for connection to tomcat ?) In all my deployments of tomcat I have never seen the point of a custom protocol that did exactly what HTTP does, so all my tomcat deployments are all HTTP, with a simple mod_proxy frontend. Well AJP/1.3 save cycle in tomcat avoiding it to re-decode headers for examples. It forward also the SSL infos if needed. And AJP/1.3 use persistant connections so it safe cycle also. jk was designed a long time ago so may be mod_proxy allready support persistant connections. Even the get Apache to server static content feature wasn't enough of a drawcard, as proper HTTP cache handling and a suitable cache solved this problem. It was far more important for me to arrange the web application as a self contained unit - I would rather be more tidy with an install at the expense of a slightly higher load, than sacrifice a clean install to save some cycles. - If you add load-balancing/fault-tolerance and AJP 1.3 support in mod_proxy you'll have about 99% of the current functionalities of jk 1.2.x. We discussed also the need for some dynamic mapping and topology discovery/update (between Apache and Tomcats Clusters). Proxy has a placeholder in it that says put the code to make decision about load balancing etc here - all that is needed is a hook and a module proxy_loadbalancing.c to make it happen. Great. And if you handle in the proxy_loadbalancing.c the JSESSION_ID, (sticky session) to map next requests to the tomcat who set it, you'll have everything needed. Of course you should also handle some mixed cases, like full round-robin, and sticky round-robin. The idea is interesting. And in fine, we like to have some JMX like functionnalities in Apache 2, in our case CMX for C Management Extension, a way to update Apache 2.x configuration while the server is running... This is possibly a whole separate project in itself. I have been meaning to work on a get-apache-config-out-of-ldap extension for a while, what it really should be is get apache config out of wherever, but this should be an Apache wide thing, not limited to a single module or technology. Well LDAP could be use for configuration outside a file. JMX/CMX goes a bit farther since it let you update some characteristics at runtime. But I agree that providing a JMX/CMX facade to Apache 2.x modules will be a good starting point. Costin will certainly clarify this point with you. In fine the discussed mod_ajp module should detect topology change in a second phase to learn for example that a tomcat in a cluster started/stopped a web application, so next requests could be redirected to another tomcat in the cluster. Also you should be able to update the load factor for each tomcat, may be having a load factor by Webapplication. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Manni Wood wrote: I very rarely post to this list, but I've been building web sites for over eight years, and want to chime in. In my experience building web sites for Fortune 500 companies (some of them Fortune 50 companies), the get Apache to serve static content while Tomcat only takes care of servlets and JSPs feature is a *huge* draw. But do you know what the biggest draws of all would be to any Apache 2 module that connects to tomcat? 1. Fantastic documentation. I cannot stress this enough. Hell, I'd even volunteer for this part. The module iteself could be poorly implemented, problematic to compile, and have truly silly defaults, but if it was incredibly well and clearly documented, I'd use it over mod_jk2 starting tomorrow. The documentation is bad, we all agree on this and when I take a look at any Apache module the doc is way better. But the lack of documentation is also due to the complexity put in jk/jk2 after years of features additions without re-factory. Also jk and jk2 inherited this, was designed to work with Apache 1.3, 2.0, IIS, iPlanet it supports also Domino and this cross compat stuff made it a very different Apache module. 2. Barring my comments in 1, a module that really and truly works, and has useful out-of-the-box (or freshly-compiled) defaults. (Maybe even, by defalt, *only* passes servelt/JSP requests to tomcat, and lets Apache handle the rest automatically.) Well documentation and good default are also requested by tomcat-dev main commiters. It's now time to refactor and redesign it with Apache 2.x (APR/AP) in mind to follow Apache 2.x admins habbits and try to make something simpler. We came on httpd-dev for advice from experts, and may be an extended mod_proxy could be the solution. But we also want to keep the AJP/1.3 and AJP/1.4 protocols since it works well and so a pure HTTP proxy is only part of the game. - Could mod_proxy be open to support AJP/1.x as tomcat connections ? - Should we learn from mod_proxy to redesign something using AJP ? Many questions which need experts answers... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: jk was designed a long time ago so may be mod_proxy allready support persistant connections. Persistence will happen on the backend on the condition there was persistence on the frontend. Generally the networks between backend and frontend are fast enough that connection setup is not a problem - a bigger problem is having expensive backend processes hanging around attached to a persistent connection that is not being used (assuming these connections are held by a tomcat thread of course, which may or may not be the case, not sure how tomcat is built internally). Great. And if you handle in the proxy_loadbalancing.c the JSESSION_ID, (sticky session) to map next requests to the tomcat who set it, you'll have everything needed. Sticky sessions has been on my list of things to support for ages - perhaps a proxy_sticky.c module could take a single parameter (the name of the parameter and/or cookie) and keep track of which server served it. If you had redundant frontends you might have a mechanism to keep track of which server is handling which session stored in a shared mechanism. A separate module might keep track of which tomcat servers are up or down, removing a server from the list of available servers on certain events (connection refused, error 4xx, 5xx, whatever). Well LDAP could be use for configuration outside a file. JMX/CMX goes a bit farther since it let you update some characteristics at runtime. But I agree that providing a JMX/CMX facade to Apache 2.x modules will be a good starting point. Costin will certainly clarify this point with you. In fine the discussed mod_ajp module should detect topology change in a second phase to learn for example that a tomcat in a cluster started/stopped a web application, so next requests could be redirected to another tomcat in the cluster. Also you should be able to update the load factor for each tomcat, may be having a load factor by Webapplication. In theory this kind of thing should not be limited to tomcat only, but to web applications (whether PHP, whatever) in general. Perhaps a mechanism that allows the backend to connect to the frontend and say status has changed, I am offering webapp XXX now, so count me into the pool. Or a mechanism for the frontend to poll the characteristics of the backend so that it can autolearn what webapp can be found where (has the advantage of not requiring a special backend module, apart from a magic URL on the backend giving relevant the information) This opens up some interesting possiblities for virtual mappings. Something like this: ProxyPass /myWebapp virtual://myWebbapp (or something) Where proxy can hand out the request to a backend that has recently said hi proxy, I serve myWebapp, feel free to contact me to fulfil a request. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Henri Gomez wrote: And what about using AJP/1.3 instead of HTTP for connection to tomcat ?) In all my deployments of tomcat I have never seen the point of a custom protocol that did exactly what HTTP does, so all my tomcat deployments are all HTTP, with a simple mod_proxy frontend. Even the get Apache to server static content feature wasn't enough of a drawcard, as proper HTTP cache handling and a suitable cache solved this problem. It was far more important for me to arrange the web application as a self contained unit - I would rather be more tidy with an install at the expense of a slightly higher load, than sacrifice a clean install to save some cycles. - If you add load-balancing/fault-tolerance and AJP 1.3 support in mod_proxy you'll have about 99% of the current functionalities of jk 1.2.x. We discussed also the need for some dynamic mapping and topology discovery/update (between Apache and Tomcats Clusters). Proxy has a placeholder in it that says put the code to make decision about load balancing etc here - all that is needed is a hook and a module proxy_loadbalancing.c to make it happen. And in fine, we like to have some JMX like functionnalities in Apache 2, in our case CMX for C Management Extension, a way to update Apache 2.x configuration while the server is running... This is possibly a whole separate project in itself. I have been meaning to work on a get-apache-config-out-of-ldap extension for a while, what it really should be is get apache config out of wherever, but this should be an Apache wide thing, not limited to a single module or technology. I think using mod_proxy is acceptable for our most important needs, as the Tomcat HTTP/1.1 connnector has acceptable performance. We would need: - JSESSIONID stickiness - persistent connections support - (and of course) load balancing (with a static worker list) with failover - bonus points for auto retry (if the request allows it) to another node when recieving a 503 status SSL client-cert support (which I have no idea how to implement with mod_proxy, or maybe I missed something) and more generally, support for doing auth on the native webserver doesn't seem to be there, which is a problem. For ease of use, we need this Tomcat policy (actually, it's not Tomcat specific, obviously) to be included in the Apache source distribution, and ready to enable. I would like a more custom solution better, but if that's the only acceptable solution for you (and you accept the module into the Apache ;) ), then I'm ok with it. In this case, we would need another, more complex connector for the advanced use cases, but we would have addressed the needs of the majority of users. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Well, the mod_proxy + enhancements for sticky session + enhancements for passing auth info sounds reasonable - and if nobody wants the JMX support, then maybe we won't need to write a new connector anyway :-) Remy will be happy - we'll only use the http connector. Costin Graham Leggett wrote: Henri Gomez wrote: jk was designed a long time ago so may be mod_proxy allready support persistant connections. Persistence will happen on the backend on the condition there was persistence on the frontend. Generally the networks between backend and frontend are fast enough that connection setup is not a problem - a bigger problem is having expensive backend processes hanging around attached to a persistent connection that is not being used (assuming these connections are held by a tomcat thread of course, which may or may not be the case, not sure how tomcat is built internally). Great. And if you handle in the proxy_loadbalancing.c the JSESSION_ID, (sticky session) to map next requests to the tomcat who set it, you'll have everything needed. Sticky sessions has been on my list of things to support for ages - perhaps a proxy_sticky.c module could take a single parameter (the name of the parameter and/or cookie) and keep track of which server served it. If you had redundant frontends you might have a mechanism to keep track of which server is handling which session stored in a shared mechanism. A separate module might keep track of which tomcat servers are up or down, removing a server from the list of available servers on certain events (connection refused, error 4xx, 5xx, whatever). Well LDAP could be use for configuration outside a file. JMX/CMX goes a bit farther since it let you update some characteristics at runtime. But I agree that providing a JMX/CMX facade to Apache 2.x modules will be a good starting point. Costin will certainly clarify this point with you. In fine the discussed mod_ajp module should detect topology change in a second phase to learn for example that a tomcat in a cluster started/stopped a web application, so next requests could be redirected to another tomcat in the cluster. Also you should be able to update the load factor for each tomcat, may be having a load factor by Webapplication. In theory this kind of thing should not be limited to tomcat only, but to web applications (whether PHP, whatever) in general. Perhaps a mechanism that allows the backend to connect to the frontend and say status has changed, I am offering webapp XXX now, so count me into the pool. Or a mechanism for the frontend to poll the characteristics of the backend so that it can autolearn what webapp can be found where (has the advantage of not requiring a special backend module, apart from a magic URL on the backend giving relevant the information) This opens up some interesting possiblities for virtual mappings. Something like this: ProxyPass /myWebapp virtual://myWebbapp (or something) Where proxy can hand out the request to a backend that has recently said hi proxy, I serve myWebapp, feel free to contact me to fulfil a request. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: It's now time to refactor and redesign it with Apache 2.x (APR/AP) in mind to follow Apache 2.x admins habbits and try to make something simpler. We came on httpd-dev for advice from experts, and may be an extended mod_proxy could be the solution. But we also want to keep the AJP/1.3 and AJP/1.4 protocols since it works well and so a pure HTTP proxy is only part of the game. I think any module that speaks ajp/1.X should be called mod_ajp, keeps things simple and clean. - Could mod_proxy be open to support AJP/1.x as tomcat connections ? I don't think mod_proxy should support ajp, rather a dedicated ajp module should. But I'm still not convinced a separate protocol is needed when HTTP exists and is supported already. The httpd serves the static content feature can be implemented through extending ProxyPass to support regular expressions, for example: ProxyPass /myWebapp/*.jsp http://tomcat/myWebapp/ I'm not sure if persistent connections over and above HTTP/1.1 keepalives is that useful. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: In all my deployments of tomcat I have never seen the point of a custom protocol that did exactly what HTTP does, so all my tomcat deployments are all HTTP, with a simple mod_proxy frontend. Even the get Apache to server static content feature wasn't enough of a drawcard, as proper HTTP cache handling and a suitable cache solved this problem. It was far more important for me to arrange the web application as a self contained unit - I would rather be more tidy with an install at the expense of a slightly higher load, than sacrifice a clean install to save some cycles. There is a bit more - we want to be able to have Apache authenticate and pass this info to tomcat for example. I don't know if this can be done with mod_proxy ( maybe have it add an extra header - but that may have security problems ). And in fine, we like to have some JMX like functionnalities in Apache 2, in our case MX for C Management Extension, a way to update Apache 2.x configuration while the server is running... This is possibly a whole separate project in itself. I have been meaning to work on a get-apache-config-out-of-ldap extension for a while, what it really should be is get apache config out of wherever, but this should be an Apache wide thing, not limited to a single module or technology. The actual problem is how to push config changes without restarting the server. Some changes obviously require restart, but chaning mappings for example should be dynamic. In MPM multithreaded mode some modules may cache session information - frequent restarts are going to be more difficult than with single threaded server. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Wayne Frazee wrote: Please pardon me for attempting to marshall the obvious however what is the advantage of AJP/1.x over HTTP? - Persistant connections, mod_jk use a pool of socket connections to avoid reopening connections between Apache and Tomcats. You could set socket timeout to make these sockets more or less persistant. Also socket keep alive could be specified to avoid firewall cut connexions without activity. - AJP/1.3 reuse Apache headers decoding to avoid duplicate works in both Apache 2 and Tomcat, these headers are sent binary serialized. - AJP/1.4 (AJP/1.3 successor), add negociation support : - Apache and tomcat could be used in a secure mode, ie they should share the same secret word. - Possible add-on is to provide compression and/or crypt of datas between Apache and Tomcat. - AJP/1.4 should add a 'service layer' which should be used to warn about topology update. Why is it worth the development time of apache volunteers? Well development is allready here, we only need to extract all AJP stuff in a separate library (discussed in tomcat-dev). And why is AJP so advantageous over HTTP/1.1 that we should redesign existing modules to use it? The initial invitation was Apache 2.x module expert advices to design at the best the jk/jk2 possible successor. We didn't ask any httpd member to work on it (even if there is some people involved in tomcat-dev/jk/jk2 allready involved in APR and Apache 2, ie Jean-Frederic Clere). I do apologize but I am not really familiar with the inner workings of tomcat as no webhost I have worked for to date has really pushed it. I think the answers to these questions would be useful for all of us who are more-or-less pure apache users/devs... Yes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Costin Manolache wrote: Well, the mod_proxy + enhancements for sticky session + enhancements for passing auth info sounds reasonable - and if nobody wants the JMX support, then maybe we won't need to write a new connector anyway :-) Remy will be happy - we'll only use the http connector. I think AJP has advantages, but if the HTTPd folks only accept a simple solution based on mod_proxy, then so be it, it'll be our entry level connector. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Henri Gomez wrote: It's now time to refactor and redesign it with Apache 2.x (APR/AP) in mind to follow Apache 2.x admins habbits and try to make something simpler. We came on httpd-dev for advice from experts, and may be an extended mod_proxy could be the solution. But we also want to keep the AJP/1.3 and AJP/1.4 protocols since it works well and so a pure HTTP proxy is only part of the game. I think any module that speaks ajp/1.X should be called mod_ajp, keeps things simple and clean. We agree and I wonder if a mod_ajp could be used in conjunction with mod_proxy ? A sort of alternative way to route requests to tomcat. - Could mod_proxy be open to support AJP/1.x as tomcat connections ? I don't think mod_proxy should support ajp, rather a dedicated ajp module should. We agree. But I'm still not convinced a separate protocol is needed when HTTP exists and is supported already. The httpd serves the static content feature can be implemented through extending ProxyPass to support regular expressions, for example: ProxyPass /myWebapp/*.jsp http://tomcat/myWebapp/ I'm not sure if persistent connections over and above HTTP/1.1 keepalives is that useful. Well let see my suggestion : ProxyPass /myWebapp/*.jsp ajp://myajpworker/ myajpworker is not a machine but a virtual resource which could be : - a physical Tomcat using its AJP/1.3 connector - a cluster of physical Tomcats using their AJP/1.3 connector And via AJP/1.4 we could make Apache 2 learn about cluster updates in real-time. Could we have this kind of Virtual Forward service used with mod_proxy ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote: Costin Manolache wrote: Well, the mod_proxy + enhancements for sticky session + enhancements for passing auth info sounds reasonable - and if nobody wants the JMX support, then maybe we won't need to write a new connector anyway :-) Remy will be happy - we'll only use the http connector. I think AJP has advantages, but if the HTTPd folks only accept a simple solution based on mod_proxy, then so be it, it'll be our entry level connector. The discussion is still open :) BTW, we could imagine that even AJP/1.4 topology update could came from HTTP/1.1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote: Costin Manolache wrote: Well, the mod_proxy + enhancements for sticky session + enhancements for passing auth info sounds reasonable - and if nobody wants the JMX support, then maybe we won't need to write a new connector anyway :-) Remy will be happy - we'll only use the http connector. I think AJP has advantages, but if the HTTPd folks only accept a simple solution based on mod_proxy, then so be it, it'll be our entry level connector. One issue here: When Apache and Tomcat are used together via AJP13: 1. The host, port, protocol, etc, are exactly that at the Apache level, i.e. one's web app sees Apache and Tomcat as 1 entity. This is a very good thing overall compared to reverse proxying (if that's the mod_proxy proposal). 2. The body content, query string, etc, are reported to one's web application precisely as sent, whereas Tomcat pre-processes them a bit more than picky, low-level request parsing code can accept. [Yes, the picky code is *too* picky, but it isn't mine :-)] -- Jess Holle
Re: Invitation to HTTPD commiters in tomcat-dev
Costin Manolache wrote: Graham Leggett wrote: In all my deployments of tomcat I have never seen the point of a custom protocol that did exactly what HTTP does, so all my tomcat deployments are all HTTP, with a simple mod_proxy frontend. Even the get Apache to server static content feature wasn't enough of a drawcard, as proper HTTP cache handling and a suitable cache solved this problem. It was far more important for me to arrange the web application as a self contained unit - I would rather be more tidy with an install at the expense of a slightly higher load, than sacrifice a clean install to save some cycles. There is a bit more - we want to be able to have Apache authenticate and pass this info to tomcat for example. I don't know if this can be done with mod_proxy ( maybe have it add an extra header - but that may have security problems ). That is a hard requirement for us as well. And in fine, we like to have some JMX like functionnalities in Apache 2, in our case MX for C Management Extension, a way to update Apache 2.x configuration while the server is running... This is possibly a whole separate project in itself. Agreed. It sounds like a great project, but a *separate* project and module. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Henri Gomez wrote: It's now time to refactor and redesign it with Apache 2.x (APR/AP) in mind to follow Apache 2.x admins habbits and try to make something simpler. We came on httpd-dev for advice from experts, and may be an extended mod_proxy could be the solution. But we also want to keep the AJP/1.3 and AJP/1.4 protocols since it works well and so a pure HTTP proxy is only part of the game. I think any module that speaks ajp/1.X should be called mod_ajp, keeps things simple and clean. - Could mod_proxy be open to support AJP/1.x as tomcat connections ? I don't think mod_proxy should support ajp, rather a dedicated ajp module should. But I'm still not convinced a separate protocol is needed when HTTP exists and is supported already. The httpd serves the static content feature can be implemented through extending ProxyPass to support regular expressions, for example: That would be a hard requirement for our usage as well. A huge reason for using Apache is to serve the static content at that level. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Wayne Frazee wrote: Please pardon me for attempting to marshall the obvious however what is the advantage of AJP/1.x over HTTP? - Persistant connections, mod_jk use a pool of socket connections to avoid reopening connections between Apache and Tomcats. You could set socket timeout to make these sockets more or less persistant. Also socket keep alive could be specified to avoid firewall cut connexions without activity. The keep alive stuff turns out to be a hard requirement for many deployments. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
I agree here, it is an excelent idea. If we want to keep it to a minimum - no multi-protocol, no jmx, no multiple servers - then making enhancements to mod_proxy and using http is much better than a mod_ajp. Tomcat httpd is fast enough, and all mod_proxy enhancements for load balancing could be used for more than tomcat. Costin Remy Maucherat wrote: I think using mod_proxy is acceptable for our most important needs, as the Tomcat HTTP/1.1 connnector has acceptable performance. We would need: - JSESSIONID stickiness - persistent connections support - (and of course) load balancing (with a static worker list) with failover - bonus points for auto retry (if the request allows it) to another node when recieving a 503 status SSL client-cert support (which I have no idea how to implement with mod_proxy, or maybe I missed something) and more generally, support for doing auth on the native webserver doesn't seem to be there, which is a problem. For ease of use, we need this Tomcat policy (actually, it's not Tomcat specific, obviously) to be included in the Apache source distribution, and ready to enable. I would like a more custom solution better, but if that's the only acceptable solution for you (and you accept the module into the Apache ;) ), then I'm ok with it. In this case, we would need another, more complex connector for the advanced use cases, but we would have addressed the needs of the majority of users. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote: I think AJP has advantages, but if the HTTPd folks only accept a simple solution based on mod_proxy, then so be it, it'll be our entry level connector. We'll certainly be interested in features like load balancing, sticky sessions, stuff like that - but the general design philosophy is that the functionality should be general enough to be used as widely as possible. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
although I'm not a commiter, I like to add 2 cents to the discussion. I like the idea of supporting JMX and the capbility of deploying a webapp without restarting the server. From the discussions so far, the task isn't simple, and may not fit the majority of users. if 80% of the users don't have this need, justifying the extra features and possibly added complexity is debatable. Would it be sufficient to create a hook for more advanced mods? There are people using tomcat's admin tool to deploy/redeploy webapps, so having the feature in mod_proxy or whatever would make the edge cases less painful. using JMX would make managing a cluster of servers easier and reduce the need to login to every single server to stop, edit conf files, and restart. peter On Tue, 20 Jul 2004 08:18:39 -0700, Costin Manolache [EMAIL PROTECTED] wrote: Well, the mod_proxy + enhancements for sticky session + enhancements for passing auth info sounds reasonable - and if nobody wants the JMX support, then maybe we won't need to write a new connector anyway :-) Remy will be happy - we'll only use the http connector. Costin Graham Leggett wrote: Henri Gomez wrote: jk was designed a long time ago so may be mod_proxy allready support persistant connections. Persistence will happen on the backend on the condition there was persistence on the frontend. Generally the networks between backend and frontend are fast enough that connection setup is not a problem - a bigger problem is having expensive backend processes hanging around attached to a persistent connection that is not being used (assuming these connections are held by a tomcat thread of course, which may or may not be the case, not sure how tomcat is built internally). Great. And if you handle in the proxy_loadbalancing.c the JSESSION_ID, (sticky session) to map next requests to the tomcat who set it, you'll have everything needed. Sticky sessions has been on my list of things to support for ages - perhaps a proxy_sticky.c module could take a single parameter (the name of the parameter and/or cookie) and keep track of which server served it. If you had redundant frontends you might have a mechanism to keep track of which server is handling which session stored in a shared mechanism. A separate module might keep track of which tomcat servers are up or down, removing a server from the list of available servers on certain events (connection refused, error 4xx, 5xx, whatever). Well LDAP could be use for configuration outside a file. JMX/CMX goes a bit farther since it let you update some characteristics at runtime. But I agree that providing a JMX/CMX facade to Apache 2.x modules will be a good starting point. Costin will certainly clarify this point with you. In fine the discussed mod_ajp module should detect topology change in a second phase to learn for example that a tomcat in a cluster started/stopped a web application, so next requests could be redirected to another tomcat in the cluster. Also you should be able to update the load factor for each tomcat, may be having a load factor by Webapplication. In theory this kind of thing should not be limited to tomcat only, but to web applications (whether PHP, whatever) in general. Perhaps a mechanism that allows the backend to connect to the frontend and say status has changed, I am offering webapp XXX now, so count me into the pool. Or a mechanism for the frontend to poll the characteristics of the backend so that it can autolearn what webapp can be found where (has the advantage of not requiring a special backend module, apart from a magic URL on the backend giving relevant the information) This opens up some interesting possiblities for virtual mappings. Something like this: ProxyPass /myWebapp virtual://myWebbapp (or something) Where proxy can hand out the request to a backend that has recently said hi proxy, I serve myWebapp, feel free to contact me to fulfil a request. Regards, Graham -- - 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]
[Fwd: Re: Invitation to HTTPD commiters in tomcat-dev]
---BeginMessage--- Manni Wood wrote: One of the things I thought AJP did that HTTP proxying to Tomcat could not (but correct me here if I'm wrong) is let the servelt container know whether or not the connection is HTTP vs. HTTPS. This sort of information needs to get passed back to the servlet container to satisfy the servlet specification. This can be easily implemented by a combination of mod_proxy/mod_dir/mod_ssl and a well defined set of request headers - this doesn't justify a whole separate protocol though. It looks like the stuff that ajp can do over and above HTTP can be implemented using HTTP without much trouble. Also, servlets (by the specification) need to be able to manipulate HTP request headers, particularly where cookies are concerned. I was under the impression that AJP allowed this, whereas mod_proxy did not, but perhaps I am wrong? mod_proxy just passes headers (excluding hop by hop headers) between httpd and the backend tomcat, I don't know of any reason why such headers can't be manipulated by a servlet container. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Jess Holle wrote: One issue here: When Apache and Tomcat are used together via AJP13: 1. The host, port, protocol, etc, are exactly that at the Apache level, i.e. one's web app sees Apache and Tomcat as 1 entity. This is a very good thing overall compared to reverse proxying (if that's the mod_proxy proposal). I have no idea how to get around that ;) This seems a showstopper: the user will have to read the connector's documentation. 2. The body content, query string, etc, are reported to one's web application precisely as sent, whereas Tomcat pre-processes them a bit more than picky, low-level request parsing code can accept. [Yes, the picky code is *too* picky, but it isn't mine :-)] I have no idea what your webapp is doing, but it's not portable. All the trasformations done respect the HTTP and servlet specifications. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote: Costin Manolache wrote: Well, the mod_proxy + enhancements for sticky session + enhancements for passing auth info sounds reasonable - and if nobody wants the JMX support, then maybe we won't need to write a new connector anyway :-) Remy will be happy - we'll only use the http connector. I think AJP has advantages, but if the HTTPd folks only accept a simple solution based on mod_proxy, then so be it, it'll be our entry level connector. AJP is an RPC protocol - the binary encoding of http headers doesn't buy us too much ( with coyote httpd ). Session stickiness is easy to add to mod_proxy, and I assume passing auth info is also possible. If we only want to use ajp for forwarding - no back channel for config - then there is no point in using RPC and binary protocol. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Well let see my suggestion : ProxyPass /myWebapp/*.jsp ajp://myajpworker/ myajpworker is not a machine but a virtual resource which could be : - a physical Tomcat using its AJP/1.3 connector - a cluster of physical Tomcats using their AJP/1.3 connector And via AJP/1.4 we could make Apache 2 learn about cluster updates in real-time. Could we have this kind of Virtual Forward service used with mod_proxy ? It's quite possible yes - currently mod_proxy has proxy_http and proxy_ftp to speak HTTP and FTP to the backend, it would make sense to put in proxy_ajp which could speak AJP to the backend, and would have the advantage of following the same config directives as the rest of proxy. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Graham Leggett wrote: Henri Gomez wrote: It's now time to refactor and redesign it with Apache 2.x (APR/AP) in mind to follow Apache 2.x admins habbits and try to make something simpler. We came on httpd-dev for advice from experts, and may be an extended mod_proxy could be the solution. But we also want to keep the AJP/1.3 and AJP/1.4 protocols since it works well and so a pure HTTP proxy is only part of the game. I think any module that speaks ajp/1.X should be called mod_ajp, keeps things simple and clean. We agree and I wonder if a mod_ajp could be used in conjunction with mod_proxy ? A sort of alternative way to route requests to tomcat. Or maybe just a channel for passing config data ( but leave request passing to mod_proxy ) ? I.e. the only thing that will remain in mod_ajp will be the autoconf and monitoring. - Could mod_proxy be open to support AJP/1.x as tomcat connections ? I don't think mod_proxy should support ajp, rather a dedicated ajp module should. We agree. But I'm still not convinced a separate protocol is needed when HTTP exists and is supported already. The httpd serves the static content feature can be implemented through extending ProxyPass to support regular expressions, for example: ProxyPass /myWebapp/*.jsp http://tomcat/myWebapp/ I'm not sure if persistent connections over and above HTTP/1.1 keepalives is that useful. Well let see my suggestion : ProxyPass /myWebapp/*.jsp ajp://myajpworker/ myajpworker is not a machine but a virtual resource which could be : - a physical Tomcat using its AJP/1.3 connector - a cluster of physical Tomcats using their AJP/1.3 connector Can we simplify this ? Let's drop the word worker too :-) The request is passed to a servlet container that may consist of one or multiple instances. Costin And via AJP/1.4 we could make Apache 2 learn about cluster updates in real-time. Could we have this kind of Virtual Forward service used with mod_proxy ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Colm MacCarthaigh wrote:
On Tue, Jul 20, 2004 at 05:20:53PM +0200, Graham Leggett wrote:
The httpd serves the static content feature can be implemented through
extending ProxyPass to support regular expressions, for example:
ProxyPass /myWebapp/*.jsp http://tomcat/myWebapp/
RewriteCond %{REQUEST_URI} ^/(.*)\.jsp$
RewriteRule (.*)http://127.0.0.1:8080$1 [P,L]
RewriteCond %{REQUEST_URI} ^/(.*)/servlet/(.*)$
RewriteRule (.*)http://127.0.0.1:8080$1 [P,L]
.. is what I have, no need for new features :)
Well I didn't see where is load-balancing and fault-tolerance here ?)
That's one of the major feature of jk/jk2 and why many companies
used jk as frontal to Tomcat cluster farms.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote: Henri Gomez wrote: Well let see my suggestion : ProxyPass /myWebapp/*.jsp ajp://myajpworker/ myajpworker is not a machine but a virtual resource which could be : - a physical Tomcat using its AJP/1.3 connector - a cluster of physical Tomcats using their AJP/1.3 connector And via AJP/1.4 we could make Apache 2 learn about cluster updates in real-time. Could we have this kind of Virtual Forward service used with mod_proxy ? It's quite possible yes - currently mod_proxy has proxy_http and proxy_ftp to speak HTTP and FTP to the backend, it would make sense to put in proxy_ajp which could speak AJP to the backend, and would have the advantage of following the same config directives as the rest of proxy. Well : - mod_proxy + proxy_ajp could be one solution. Now what about the mod_proxy load-balancing add-on ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Costin Manolache wrote: Henri Gomez wrote: Graham Leggett wrote: Henri Gomez wrote: It's now time to refactor and redesign it with Apache 2.x (APR/AP) in mind to follow Apache 2.x admins habbits and try to make something simpler. We came on httpd-dev for advice from experts, and may be an extended mod_proxy could be the solution. But we also want to keep the AJP/1.3 and AJP/1.4 protocols since it works well and so a pure HTTP proxy is only part of the game. I think any module that speaks ajp/1.X should be called mod_ajp, keeps things simple and clean. We agree and I wonder if a mod_ajp could be used in conjunction with mod_proxy ? A sort of alternative way to route requests to tomcat. Or maybe just a channel for passing config data ( but leave request passing to mod_proxy ) ? I.e. the only thing that will remain in mod_ajp will be the autoconf and monitoring. - Could mod_proxy be open to support AJP/1.x as tomcat connections ? I don't think mod_proxy should support ajp, rather a dedicated ajp module should. We agree. But I'm still not convinced a separate protocol is needed when HTTP exists and is supported already. The httpd serves the static content feature can be implemented through extending ProxyPass to support regular expressions, for example: ProxyPass /myWebapp/*.jsp http://tomcat/myWebapp/ I'm not sure if persistent connections over and above HTTP/1.1 keepalives is that useful. Well let see my suggestion : ProxyPass /myWebapp/*.jsp ajp://myajpworker/ myajpworker is not a machine but a virtual resource which could be : - a physical Tomcat using its AJP/1.3 connector - a cluster of physical Tomcats using their AJP/1.3 connector Can we simplify this ? Let's drop the word worker too :-) The request is passed to a servlet container that may consist of one or multiple instances. Agreed, remove the old terms. The proposal about mod_proxy + proxy_ajp could be something fine isn't it. And proxy_ajp could map to a dynamically updated ajp resource ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Manni Wood wrote: I asked you to develop your argument ;) Ah. I'm trying my best. :-) May be you could take a look as documentalist ?) I would very happily volunteer my time to document this new module. Where do I sign up? How do I gain acceptance as a documentor, and if I am accepted, what would my next steps be? I'd love to help. Well what about writing jk 1.2.x but following Apache 2.0 xml documentation. You could start by merging Apache 2.0 directive, like JkMount : http://jakarta.apache.org/tomcat/connectors-doc/jk2/jk/aphowto.html and workers.properties : http://jakarta.apache.org/tomcat/connectors-doc/jk2/jk/workershowto.html Thanks to join us at tomcat-dev :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Can we simplify this ? Let's drop the word worker too :-) The request is passed to a servlet container that may consist of one or multiple instances. Agreed, remove the old terms. The proposal about mod_proxy + proxy_ajp could be something fine isn't it. And proxy_ajp could map to a dynamically updated ajp resource ? Well, we could drop ajp as well from proxy-related config. The important thing is to have the proxy know about a cluster - and provide hooks to allow this to be dynamically configured. mod_ajp would deal only with the cluster ( and other ? ) configuration. Security and extra info about request will be encoded in special headers ( and of course, something should filter those headers from the internet to prevent security issues ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: Invitation to HTTPD commiters in tomcat-dev]
---BeginMessage--- Henri Gomez wrote: - mod_proxy + proxy_ajp could be one solution. Now what about the mod_proxy load-balancing add-on ? Would be a completely separate module. The way proxy works, is that it: - obtains the IP address to connect to (currently via DNS round robin, but a module proxy_loadbalancer might make a more intelligent choice of IP address) - opens a connection to that address (unless a connection is already open due to keepalive behaviour, in which case just use that) - pass control to the backend protocol handler (proxy_http, or proxy_ftp, or proxy_ajp) Load balancing would happen at step one. Such a module would need a way to decide load (in the simplest case, by spreading load, in a more complex case, by actually asking the backend servers for the loads so to make a more intelligent decision). Such a module need not work with tomcat only, but with any backend, and any protocol. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: - mod_proxy + proxy_ajp could be one solution. Now what about the mod_proxy load-balancing add-on ? Would be a completely separate module. The way proxy works, is that it: - obtains the IP address to connect to (currently via DNS round robin, but a module proxy_loadbalancer might make a more intelligent choice of IP address) - opens a connection to that address (unless a connection is already open due to keepalive behaviour, in which case just use that) - pass control to the backend protocol handler (proxy_http, or proxy_ftp, or proxy_ajp) Load balancing would happen at step one. Such a module would need a way to decide load (in the simplest case, by spreading load, in a more complex case, by actually asking the backend servers for the loads so to make a more intelligent decision). Such a module need not work with tomcat only, but with any backend, and any protocol. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Invitation to HTTPD commiters in tomcat-dev
Remy Maucherat wrote: Jess Holle wrote: One issue here: When Apache and Tomcat are used together via AJP13: 1. The host, port, protocol, etc, are exactly that at the Apache level, i.e. one's web app sees Apache and Tomcat as 1 entity. This is a very good thing overall compared to reverse proxying (if that's the mod_proxy proposal). I have no idea how to get around that ;) This seems a showstopper: the user will have to read the connector's documentation. Certainly things function in a reverse proxy environment and so the more complex situation is handled. The issue is that individual developers *can* do bad things by assuming that the request protocol is that they should use in base tags, etc. Overall, that would just be life, though and is insufficient reason not to leverage mod_proxy. 2. The body content, query string, etc, are reported to one's web application precisely as sent, whereas Tomcat pre-processes them a bit more than picky, low-level request parsing code can accept. [Yes, the picky code is *too* picky, but it isn't mine :-)] I have no idea what your webapp is doing, but it's not portable. All the trasformations done respect the HTTP and servlet specifications. Actually it is rather portable and does not break any spec to the best of my knowledge. It just assumes it can get at the original content body stream, request string, etc, as an alternative to getParameter() without missing anything. Why this is the case is a long story. I also miss forget exactly where things fall down, but Apache, iPlanet (with embedded servlet engine), and IIS (with Tomcat) all work (except config issues with IIS 6...) This appears to be far removed from most folks' experience, so I guess Tomcat's httpd is good enough for most. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
Henri Gomez wrote: Now what about the mod_proxy load-balancing add-on ? The thing I'm most happy about with the simple load balancing + sticky session + failover is that the development would be short (hopefully), be bundled with Apache quickly, and could really help people's experience with Tomcat :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invitation to HTTPD commiters in tomcat-dev
TAKE ME OFF THIS MAILING LIST IMMEDIATELY... I DID NOT REQUEST THIS AND I DO NOT WANT ANOTHER EMAIL FROM JAKARTA.APACHE.ORG Graham Leggett [EMAIL PROTECTED] wrote: Henri Gomez wrote: jk was designed a long time ago so may be mod_proxy allready support persistant connections. Persistence will happen on the backend on the condition there was persistence on the frontend. Generally the networks between backend and frontend are fast enough that connection setup is not a problem - a bigger problem is having expensive backend processes hanging around attached to a persistent connection that is not being used (assuming these connections are held by a tomcat thread of course, which may or may not be the case, not sure how tomcat is built internally). Great. And if you handle in the proxy_loadbalancing.c the JSESSION_ID, (sticky session) to map next requests to the tomcat who set it, you'll have everything needed. Sticky sessions has been on my list of things to support for ages - perhaps a proxy_sticky.c module could take a single parameter (the name of the parameter and/or cookie) and keep track of which server served it. If you had redundant frontends you might have a mechanism to keep track of which server is handling which session stored in a shared mechanism. A separate module might keep track of which tomcat servers are up or down, removing a server from the list of available servers on certain events (connection refused, error 4xx, 5xx, whatever). Well LDAP could be use for configuration outside a file. JMX/CMX goes a bit farther since it let you update some characteristics at runtime. But I agree that providing a JMX/CMX facade to Apache 2.x modules will be a good starting point. Costin will certainly clarify this point with you. In fine the discussed mod_ajp module should detect topology change in a second phase to learn for example that a tomcat in a cluster started/stopped a web application, so next requests could be redirected to another tomcat in the cluster. Also you should be able to update the load factor for each tomcat, may be having a load factor by Webapplication. In theory this kind of thing should not be limited to tomcat only, but to web applications (whether PHP, whatever) in general. Perhaps a mechanism that allows the backend to connect to the frontend and say status has changed, I am offering webapp XXX now, so count me into the pool. Or a mechanism for the frontend to poll the characteristics of the backend so that it can autolearn what webapp can be found where (has the advantage of not requiring a special backend module, apart from a magic URL on the backend giving relevant the information) This opens up some interesting possiblities for virtual mappings. Something like this: ProxyPass /myWebapp virtual://myWebbapp (or something) Where proxy can hand out the request to a backend that has recently said hi proxy, I serve myWebapp, feel free to contact me to fulfil a request. Regards, Graham -- ATTACHMENT part 2 application/x-pkcs7-signature name=smime.p7s - Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign!
Re: Invitation to HTTPD commiters in tomcat-dev
Colm MacCarthaigh wrote: Using OPTIONS has the advantage of being backwards compatible, if you send OPTIONS to a plain-old HTTP receiver, the standard ACK can be taken to mean yep, I'm here. Intelligent backends (read: modify tomcat and co slightly) can have an X-header or whatever to go I'm accepting this, this and this, and my current load is this. This makes sense - you would just need to tell proxy the possible servers, and an intelligent load balancer might try find out the current status of those servers based on querying options to find out on a regular basis. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
