Re: Mod_ajp initial
Hi, On Son 01.08.2004 11:46, Mladen Turk wrote: You can take a look at current development at j-t-c/ajp and http_wrap that mimics the libhttpd functionality and enables console apps to behave like a http server. Thanx i will look there ;-) This is the fundamental difference from JK/JK2 where we had our own web server abstraction layer and API. Ajp will use only the Apache2 API and nothing more. Thanx for your explanation ;-) I think it *ajp* would not be backported to apache 1.3. Writing apache2 wrapper shouldn't be such a big deal, cause in any web server you have headers, output and input stream, etc... I will study the http_wrap-Code ;-) al ,-) PS: whith j-t-c you mean Jakarte-Tomcat-Connector, right? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mod_ajp initial
Alexander Lazic wrote: > > > >Since we plan to developp an AJP library, it will ease the task for > >ajp_proxy and we could validate many points like this and have a > >release rate independant from the HTTPD 2.0/2.1 rr. > > Well does you plan to bind this library to apr? Yes, but also to the libhttpd. > I ask because i want to use tomcat without > apache-httpd-webserver and therefore it would be nice if the > lib don't depend on to many or to great libs. > You can take a look at current development at j-t-c/ajp and http_wrap that mimics the libhttpd functionality and enables console apps to behave like a http server. > I plan to use this webserver: > > http://www.fefe.de/gatling/ > http://cthulhu.fnord.at/ > You will have to write your own implementation of the ap_xxx functions (httpd_wrap). Since almost all web servers tend to behave similar, using HTTP protocol you will need to find a way to rewrite the apache API on top of your web server API. Exactly the same will be done if we eventually decide to make a IIS or any other server support. We will expect that IIS behaves like Apache2 does, not modifying libajp but rather writing httpd_iis_wrap. This is the fundamental difference from JK/JK2 where we had our own web server abstraction layer and API. Ajp will use only the Apache2 API and nothing more. Writing apache2 wrapper shouldn't be such a big deal, cause in any web server you have headers, output and input stream, etc... MT. smime.p7s Description: S/MIME cryptographic signature
Re: Mod_ajp initial
Hi, On Mon 26.07.2004 12:01, Henri Gomez wrote: Since we plan to developp an AJP library, it will ease the task for ajp_proxy and we could validate many points like this and have a release rate independant from the HTTPD 2.0/2.1 rr. Well does you plan to bind this library to apr? I ask because i want to use tomcat without apache-httpd-webserver and therefore it would be nice if the lib don't depend on to many or to great libs. I plan to use this webserver: http://www.fefe.de/gatling/ http://cthulhu.fnord.at/ al ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
I suspect isapi_redirect will continue working for some time (though it's URI pattern mapping really did not work for quite some time until 1.2.6). mod_auth_sspi seems to solve the NTLM issue fairly nicely. The political reasons are, however, without any technical basis and thus cannot realistically be addressed save through placation Having just spent over a week getting IIS 6 and isapi_redirect working for a complex system, I've got mixed feelings here. I'd like this to keep working (ideally without any "IIS 5 isolation mode" workarounds) and placating customers, but overall I think Apache 2 is better solution and a better use of the community's time. Now if someone could take over ownership/maintenance for mod_auth_sspi, I'd feel better about IIS support slowly withering away -- Jess Holle Ari Suutari wrote: Hi, I think we do have agreement on droping IIS/iPlanet. Does this mean that in the future there won't be a way to integrate tomcat to IIS ? We have some customers that require use of IIS as frontend (for either political reasons or they want to use integrated windows authentication feature of IIS). Of course there are commercial products for this, but tomcat has just been a very good companion to IIS in our systems. So I hope that someone maintains some kind of solution for IIS integration. Ari S. -- Ari Suutari, Syncron Tech Oy, Finland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Costin Manolache wrote: Henri Gomez wrote: What about adding/updating of webapps ? Is this a feature that will never be added ( because if it will be and it is not part of the design - then we're back to spaghetti ) Well if you recall my AJP/1.4 proposal it was on my wish-list : Adding/Removing/Updating a webapp on a tomcat instance is on the features list. I think it should be done by adding/removing the mapping between Apache and the particular Tomcat instance. Henri, My point was that "just apache2+tcp+ajp and nothing else" is not realistic. You can't expect to start with a trivial feature, forwarding requests - and then be able to grow without pain to support very complex features like add/remove of webapps. well this first step could be an initial mod_ajp or mod_proxy + proxy_ajp and we all agree on this. We tried this already. It was before mod_proxy and APR :) Major features have a big impact on the code. In this case - if you want to add/remove/update webapps - you need to implement your own mapper - and the integration with apache ( where location is used ) no longer works. Or you need to hack apache to support changes to the mapper. Well I see that Graham seems open about Dynamic stuff in Apache 2 and I'm sure he'll speak for us in httpd-dev list. Meanwhile we could works on mod_ajp step 2, to add such features. If you want to support cluster reconfiguration - storing the list of cluster servers in httpd.conf may make things harder to save. So you may want to save the properties where you allow changes in a separate file ( htpasswd is an example of apache conf that is not in httpd.conf ). But then you'll have 2 ways to configure something, and more complexity in the code. Costin you know me better than that ;) I was thinking something more evolved. For instance you could have in httpd.conf the minimal settings to reach at least one Tomcat. If that Tomcat know the tipology, it could forward real-time topology update to Apache via AJP/1.4 or whatever scheme you could prefer, ie ajp_status/ajp_update handlers. What we need is something new an clean for make good fundation for more evolved code, and that's why we want ajplib, a simple mod_ajp, proxy_ajp if Graham agree. Next step will we dynamic update using if needed our own mapper, and I think Mladen has some ideas for it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Henri Gomez wrote: What about adding/updating of webapps ? Is this a feature that will never be added ( because if it will be and it is not part of the design - then we're back to spaghetti ) Well if you recall my AJP/1.4 proposal it was on my wish-list : Adding/Removing/Updating a webapp on a tomcat instance is on the features list. I think it should be done by adding/removing the mapping between Apache and the particular Tomcat instance. Henri, My point was that "just apache2+tcp+ajp and nothing else" is not realistic. You can't expect to start with a trivial feature, forwarding requests - and then be able to grow without pain to support very complex features like add/remove of webapps. We tried this already. Major features have a big impact on the code. In this case - if you want to add/remove/update webapps - you need to implement your own mapper - and the integration with apache ( where location is used ) no longer works. Or you need to hack apache to support changes to the mapper. If you want to support cluster reconfiguration - storing the list of cluster servers in httpd.conf may make things harder to save. So you may want to save the properties where you allow changes in a separate file ( htpasswd is an example of apache conf that is not in httpd.conf ). But then you'll have 2 ways to configure something, and more complexity in the code. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Ari Suutari wrote: Hi, I think we do have agreement on droping IIS/iPlanet. Does this mean that in the future there won't be a way to integrate tomcat to IIS ? We have some customers that require use of IIS as frontend (for either political reasons or they want to use integrated windows authentication feature of IIS). Of course there are commercial products for this, but tomcat has just been a very good companion to IIS in our systems. So I hope that someone maintains some kind of solution for IIS integration. Well for IIS users could still use jk 1.2.x but this one will be no more activly maintened. We'll produce an ajp library, requiring APR. And if someone with good IIS knowledge want to use it to link IIS/Tomcat, we could still add the IIS support in jakarta-tomcat-connectors. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Costin Manolache wrote: Henri Gomez wrote: Costin Manolache wrote: Mladen Turk wrote: Of course, no one is forced to participate in development, but everyone is welcome. The only question is do we have enough juice to make it official. AFICT, Remy, Henri and myself are in favor. But frankly I see no reason for someone to object, cause it's open source after all, and it doesn't break nothing that already exists. I'm not in favor, quite the contrary. And I thing there are reasons to object - "doesn't break anthing that exists" is not the only criteria used in apache. "Is it the best solution ?" can be used sometimes. Well I've got more than one reason to object to current jk2 and jk. This is not about objecting to current jk and jk2. They are where they are because of some design and requirement errors. The whole point is to avoid this. It should be obvious that adding important features as an after-tough and starting with "just code that doesn't break" instead of a sound requirements and design will likely lead to the same spaghetti and mess in the long run. I said that some known Tomcat instances, Remy asked us to avoid the old jk/jk2 naming, are set in Apache 2 by default, but nothing prevent us to add new instance dynamically, via ajp_status or mod_status or whatever (may be even via AJP/1.4). Nothing prevented us to add any feature to mod_jk.x either. 3 years ago we didn't know all those requirements - few people were thinking at that time that tomcat will be used in "allways on" configurations. And if "dynamic config" is not on the list - then it won't solve the problem for people who really need apache+tomcat, i.e. many large sites with uptime requirements. Why confuse the people with yet another connector - and what hope can we have it will not have the same fate as mod_webapp ? I'm handling sites requiring this kind of requirement and it's high on my mod_ajp features wish list. When you operate sites which works 24/24 and 7/7 and need to add horse power, it's a nightmare to have to wait some period in the night to make the Apache server update and restart. Also admins may want to add some power for a short period of time, so adding and removing such instances should be easy and quick. Ok, so what is the plan to support this in mod_ajp ? Is this on the list of requirements - and for that matters, what is the list ? If it is, again, how do you plan to support it ? It's not a trivial issue, reconfiguration is very hard - and most likely to create a lot of spaghetti. It's not funny how we allways refuse to learn from our mistakes, and periodically repeat them Well I'd like to resume the mod_ajp goal : - an APR/Apache 2 specific module (no more mess with #ifdef for 30 differents OS, we're in 2004). - extract ajp stuff and put it in an ajp library, which could be used outside within the Apache 2.0 module, used by proxy_ajp and of course in others applications, ie ajp-bench. - Study what has been done in mod_proxy to follow the start of art in Apache 2.x dev and make sure we could works with others AP2 modules. - Add/Remove/Update of Tomcat instances, and allow to attach/map them to URI and LB instances. What about adding/updating of webapps ? Is this a feature that will never be added ( because if it will be and it is not part of the design - then we're back to spaghetti ) Well if you recall my AJP/1.4 proposal it was on my wish-list : Adding/Removing/Updating a webapp on a tomcat instance is on the features list. I think it should be done by adding/removing the mapping between Apache and the particular Tomcat instance. Costin will probably mention JMX/CMX support, but I think this is something so important that it should be in HTTPD-dev and not only in mod_ajp. JMX is just a mean to an end. The goal is dynamic configuration ( i.e. without restart ). Yes, it should be more available in httpd-dev ( they do have some with .htaccess, etc ), but we have few clear use cases they don't. Well - dynamic add/remove of webapps is quite trivial in apache, you can add cgis/php/etc without restarting the server even today. JMX/CMX will be a great interest for all HTTPD modules, to update for examples Location/Directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Graham Leggett wrote: Mladen Turk wrote: If I make a design flaw, and the entire project gets unusable, it will make it just something like mod_java, mod_warp, mod_jk and mod_jk2 are... Dead. Nobody will get hanged for that. Some code is always better than no code - at best, the code will be good enough to fit the needs, and will end up in wide use. At worst, the writers will say "we learned some lessons from this" and try again. OSS is often using the XP methodology and we all learn from mistakes. BTW, we should cleanup many things to see what good parts could be used in HTTPD-dev, and it will start ad minima by extracting AJP part from jk/jk2... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mod_ajp initial
Costin Manolache wrote: > > I agree with libajp.so. > > I don't agree we need to develop new connector for apache2.0. > If we can't get it backported to 2.0 - then we can just > provide a separate build ( mod_proxy21 ). > Sure, that's the one of solutions. > > that, and BTW I'm working on that together with Graham, but even he > > can not say for sure it's going to be in 2.0 branch. > > There is also a question of development infrastructure, cause we > > cannot use the httpd-cvs for that, so we'll need to make some > > compromises, writing few lines of code twice, and hope that > somone will apply the patch :). > > > We can very well put a copy of mod_proxy in our cvs while it > is experimental - and give Graham access. The module can be > tested/developed with both apache20 and 21. > I think I proposed something like too, and it is perhaps the most pragmatic approach. Only not sure if there are official distros with mod_proxy compiled in. In that case we'll need some namespace protection. We will still need my scoreboard patch back propagated to 2.0, so we can use lb without writing our own implementation. Graham, are you willing to become a j-t-c committer? MT, smime.p7s Description: S/MIME cryptographic signature
Re: Mod_ajp initial
Hi, > I think we do have agreement on droping IIS/iPlanet. Does this mean that in the future there won't be a way to integrate tomcat to IIS ? We have some customers that require use of IIS as frontend (for either political reasons or they want to use integrated windows authentication feature of IIS). Of course there are commercial products for this, but tomcat has just been a very good companion to IIS in our systems. So I hope that someone maintains some kind of solution for IIS integration. Ari S. -- Ari Suutari, Syncron Tech Oy, Finland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Mladen Turk wrote: Well, the way I see (think that Henri has the similar ideas) is to have the ajp protocol lib, usable to communicate to TC from any container, not only http server, and mod_ajp as a layer on top of it _only_ for Apache 2.0 branch _and_only_ if the proxy_ajp doesn't get back propagated from 2.1 branch. I agree with libajp.so. I don't agree we need to develop new connector for apache2.0. If we can't get it backported to 2.0 - then we can just provide a separate build ( mod_proxy21 ). So from the start we know what the final goal is, and what the life cycle of it would be. The code itself (at least the ajp protocol library) will not be a waste, cause we'll use it for both proxy_ajp and any later bizarre usage. To effectively test the new ajp code we need some framework, simple enough and Apache2 centric. We could use the current mod_proxy for that, but it's current design need some changes to be able to support that, and BTW I'm working on that together with Graham, but even he can not say for sure it's going to be in 2.0 branch. There is also a question of development infrastructure, cause we cannot use the httpd-cvs for that, so we'll need to make some compromises, writing few lines of code twice, and hope that somone will apply the patch :). We can very well put a copy of mod_proxy in our cvs while it is experimental - and give Graham access. The module can be tested/developed with both apache20 and 21. I don't think infrastructure is the biggest problem. We are all on apache. My concern is that we are just repeating the history of the first 4 connectors - by writting some initial code that solves the easy problem ( sending requests to tomcat ), and hoping the rest can be added without getting back to spaghetti. Well, the only thing you can not beat is the time. It (the time) has a strange side effect to make the things older. I clearly remember a day when I stood speechless in front of a VAX mainframe with 1MB of RAM, wondering who will ever need that and for what. My point was that repeating a mistake 4 times should be enough, we don't need a 5th repetition of the same history. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mod_ajp initial
Costin Manolache wrote: > > AFICR you said that you will have something to share, and > I'd love to see > > some other, perhaps better ideas. > > No, I'm trying stuff on java side. > OK. > And just like with code - I don't think we are missing > propositions or > ideas. What is missing is an agreement over what features we > are going > to support ( and more exactly - not support ), as well as a > clear plan > on how to support them without spaghetti. > > I think we do have agreement on droping IIS/iPlanet. We had > agreement on > droping pluggable protocol Apache2, ajp13, TCP/IP With possible dynamic config in stage 2 and ajp14 protocol extension using crypto and compression. That's it. We said that couple of times. > - but that's now back with the > discussion on > mod_proxy ( which also involves pluggable protocol ). > True, the work on that has been initiated, but it has a fundamental difference being included in core httpd distribution. Only that fact is a sufficient reason to forget that 'no plugable protocol' agreement, thought, and of course the fact that the proxy is deeply integrated into the core of httpd, as well as our protocol will consequently. > > Yes, we do have plenty of connectors, and most were written > very fast - >mod_jserv, mod_jk, mod_jk2, mod_webapp, mod_proxy. > > Having a 6th codebase - especially in the context of the growing > agreement over mod_proxy as a long-term solution - is not > what is missing. > Well, the way I see (think that Henri has the similar ideas) is to have the ajp protocol lib, usable to communicate to TC from any container, not only http server, and mod_ajp as a layer on top of it _only_ for Apache 2.0 branch _and_only_ if the proxy_ajp doesn't get back propagated from 2.1 branch. So from the start we know what the final goal is, and what the life cycle of it would be. The code itself (at least the ajp protocol library) will not be a waste, cause we'll use it for both proxy_ajp and any later bizarre usage. To effectively test the new ajp code we need some framework, simple enough and Apache2 centric. We could use the current mod_proxy for that, but it's current design need some changes to be able to support that, and BTW I'm working on that together with Graham, but even he can not say for sure it's going to be in 2.0 branch. There is also a question of development infrastructure, cause we cannot use the httpd-cvs for that, so we'll need to make some compromises, writing few lines of code twice, and hope that somone will apply the patch :). > My concern is that we are just repeating the history of the first 4 > connectors - by writting some initial code that solves the > easy problem > ( sending requests to tomcat ), and hoping the rest can be > added without > getting back to spaghetti. > Well, the only thing you can not beat is the time. It (the time) has a strange side effect to make the things older. I clearly remember a day when I stood speechless in front of a VAX mainframe with 1MB of RAM, wondering who will ever need that and for what. MT. smime.p7s Description: S/MIME cryptographic signature
Re: Mod_ajp initial
Remy Maucherat wrote: jean-frederic clere wrote: We have noted that mod_proxy + mod_proxy_http are slow compared with mod_jk. I think that the next step should be to try to find "why" instead writting a new modules. May be a quick hacked mod_proxy_ajp to replace mod_proxy_http is the first step. Note that I am a bit reluctant to start a new module because I already had lost a lot of time in mod_webapp ;-( A lot of people lost time on various connectors, so you're not alone ;) (the list includes me with my old HTTP connector in Tomcat 4.0) Rémy Mod_jk, mod_jk2, http connector in 3.3, few ajp connectors and jserv on the java side, etc - it seems I lost quite a bit of time on connectors :-) I'm more worried about lost of important features and things we learned than lost of code or even time. Most of the time was well spent - to learn stuff and solve problems, maybe not with the best solution but the best we could at that point. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Mladen Turk wrote: Costin Manolache wrote: Mladen Turk wrote: If I make a design flaw, and the entire project gets unusable, it will make it just something like mod_java, mod_warp, mod_jk and mod_jk2 are... Dead. Nobody will get hanged for that. I don't think the goal is to accumulate more mod_warp, mod_jk, mod_jk2 - but to learn from the past errors and do something better. OK then, do you have some other proposition, or just saying what we all said discussing this subject. AFICR you said that you will have something to share, and I'd love to see some other, perhaps better ideas. No, I'm trying stuff on java side. And just like with code - I don't think we are missing propositions or ideas. What is missing is an agreement over what features we are going to support ( and more exactly - not support ), as well as a clear plan on how to support them without spaghetti. I think we do have agreement on droping IIS/iPlanet. We had agreement on droping pluggable protocol - but that's now back with the discussion on mod_proxy ( which also involves pluggable protocol ). Well, both Apache2 and Tomcat ( even tomcat3 ) had some design and requirements ( == goals ). And at least in apache2 I remember they did spent the time to discuss this and figure out the best design ( and quite a few "creative" solutions were not accepted ). Take a look at apache filters, or APR. We are discussing too, right? And if you follow the discussion, you will find enough 'design leads'. There is nothing in the source tree jet, and the thread is named 'initial'. After all, I wrote that initial code in a single afternoon, so it's not such a big deal. Yes, we do have plenty of connectors, and most were written very fast - mod_jserv, mod_jk, mod_jk2, mod_webapp, mod_proxy. Having a 6th codebase - especially in the context of the growing agreement over mod_proxy as a long-term solution - is not what is missing. My concern is that we are just repeating the history of the first 4 connectors - by writting some initial code that solves the easy problem ( sending requests to tomcat ), and hoping the rest can be added without getting back to spaghetti. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mod_ajp initial
Costin Manolache wrote: > > Mladen Turk wrote: > > > > If I make a design flaw, and the entire project gets > unusable, it will > > make it just something like mod_java, mod_warp, mod_jk and > mod_jk2 are... Dead. > > Nobody will get hanged for that. > > > I don't think the goal is to accumulate more mod_warp, > mod_jk, mod_jk2 - but to learn from the past errors and do > something better. > OK then, do you have some other proposition, or just saying what we all said discussing this subject. AFICR you said that you will have something to share, and I'd love to see some other, perhaps better ideas. > > Well, both Apache2 and Tomcat ( even tomcat3 ) had some design and > requirements ( == goals ). > > And at least in apache2 I remember they did spent the time to discuss > this and figure out the best design ( and quite a few "creative" > solutions were not accepted ). Take a look at apache filters, or APR. > We are discussing too, right? And if you follow the discussion, you will find enough 'design leads'. There is nothing in the source tree jet, and the thread is named 'initial'. After all, I wrote that initial code in a single afternoon, so it's not such a big deal. MT. smime.p7s Description: S/MIME cryptographic signature
Re: Mod_ajp initial
jean-frederic clere wrote: We have noted that mod_proxy + mod_proxy_http are slow compared with mod_jk. I think that the next step should be to try to find "why" instead writting a new modules. May be a quick hacked mod_proxy_ajp to replace mod_proxy_http is the first step. Note that I am a bit reluctant to start a new module because I already had lost a lot of time in mod_webapp ;-( A lot of people lost time on various connectors, so you're not alone ;) (the list includes me with my old HTTP connector in Tomcat 4.0) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Henri Gomez wrote: Costin Manolache wrote: Mladen Turk wrote: Of course, no one is forced to participate in development, but everyone is welcome. The only question is do we have enough juice to make it official. AFICT, Remy, Henri and myself are in favor. But frankly I see no reason for someone to object, cause it's open source after all, and it doesn't break nothing that already exists. I'm not in favor, quite the contrary. And I thing there are reasons to object - "doesn't break anthing that exists" is not the only criteria used in apache. "Is it the best solution ?" can be used sometimes. Well I've got more than one reason to object to current jk2 and jk. This is not about objecting to current jk and jk2. They are where they are because of some design and requirement errors. The whole point is to avoid this. It should be obvious that adding important features as an after-tough and starting with "just code that doesn't break" instead of a sound requirements and design will likely lead to the same spaghetti and mess in the long run. I said that some known Tomcat instances, Remy asked us to avoid the old jk/jk2 naming, are set in Apache 2 by default, but nothing prevent us to add new instance dynamically, via ajp_status or mod_status or whatever (may be even via AJP/1.4). Nothing prevented us to add any feature to mod_jk.x either. 3 years ago we didn't know all those requirements - few people were thinking at that time that tomcat will be used in "allways on" configurations. Now we do. And if "dynamic config" is not on the list - then it won't solve the problem for people who really need apache+tomcat, i.e. many large sites with uptime requirements. Why confuse the people with yet another connector - and what hope can we have it will not have the same fate as mod_webapp ? I'm handling sites requiring this kind of requirement and it's high on my mod_ajp features wish list. When you operate sites which works 24/24 and 7/7 and need to add horse power, it's a nightmare to have to wait some period in the night to make the Apache server update and restart. Also admins may want to add some power for a short period of time, so adding and removing such instances should be easy and quick. Ok, so what is the plan to support this in mod_ajp ? Is this on the list of requirements - and for that matters, what is the list ? If it is, again, how do you plan to support it ? It's not a trivial issue, reconfiguration is very hard - and most likely to create a lot of spaghetti. Well I'd like to resume the mod_ajp goal : - an APR/Apache 2 specific module (no more mess with #ifdef for 30 differents OS, we're in 2004). - extract ajp stuff and put it in an ajp library, which could be used outside within the Apache 2.0 module, used by proxy_ajp and of course in others applications, ie ajp-bench. - Study what has been done in mod_proxy to follow the start of art in Apache 2.x dev and make sure we could works with others AP2 modules. - Add/Remove/Update of Tomcat instances, and allow to attach/map them to URI and LB instances. What about adding/updating of webapps ? Is this a feature that will never be added ( because if it will be and it is not part of the design - then we're back to spaghetti ) Costin will probably mention JMX/CMX support, but I think this is something so important that it should be in HTTPD-dev and not only in mod_ajp. JMX is just a mean to an end. The goal is dynamic configuration ( i.e. without restart ). Yes, it should be more available in httpd-dev ( they do have some with .htaccess, etc ), but we have few clear use cases they don't. Well - dynamic add/remove of webapps is quite trivial in apache, you can add cgis/php/etc without restarting the server even today. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Henri Gomez wrote: Costin Manolache wrote: Mladen Turk wrote: Of course, no one is forced to participate in development, but everyone is welcome. The only question is do we have enough juice to make it official. AFICT, Remy, Henri and myself are in favor. But frankly I see no reason for someone to object, cause it's open source after all, and it doesn't break nothing that already exists. I'm not in favor, quite the contrary. And I thing there are reasons to object - "doesn't break anthing that exists" is not the only criteria used in apache. "Is it the best solution ?" can be used sometimes. Well I've got more than one reason to object to current jk2 and jk. This is not about objecting to current jk and jk2. They are where they are because of some design and requirement errors. The whole point is to avoid this. It should be obvious that adding important features as an after-tough and starting with "just code that doesn't break" instead of a sound requirements and design will likely lead to the same spaghetti and mess in the long run. I said that some known Tomcat instances, Remy asked us to avoid the old jk/jk2 naming, are set in Apache 2 by default, but nothing prevent us to add new instance dynamically, via ajp_status or mod_status or whatever (may be even via AJP/1.4). Nothing prevented us to add any feature to mod_jk.x either. 3 years ago we didn't know all those requirements - few people were thinking at that time that tomcat will be used in "allways on" configurations. And if "dynamic config" is not on the list - then it won't solve the problem for people who really need apache+tomcat, i.e. many large sites with uptime requirements. Why confuse the people with yet another connector - and what hope can we have it will not have the same fate as mod_webapp ? I'm handling sites requiring this kind of requirement and it's high on my mod_ajp features wish list. When you operate sites which works 24/24 and 7/7 and need to add horse power, it's a nightmare to have to wait some period in the night to make the Apache server update and restart. Also admins may want to add some power for a short period of time, so adding and removing such instances should be easy and quick. Ok, so what is the plan to support this in mod_ajp ? Is this on the list of requirements - and for that matters, what is the list ? If it is, again, how do you plan to support it ? It's not a trivial issue, reconfiguration is very hard - and most likely to create a lot of spaghetti. It's not funny how we allways refuse to learn from our mistakes, and periodically repeat them Well I'd like to resume the mod_ajp goal : - an APR/Apache 2 specific module (no more mess with #ifdef for 30 differents OS, we're in 2004). - extract ajp stuff and put it in an ajp library, which could be used outside within the Apache 2.0 module, used by proxy_ajp and of course in others applications, ie ajp-bench. - Study what has been done in mod_proxy to follow the start of art in Apache 2.x dev and make sure we could works with others AP2 modules. - Add/Remove/Update of Tomcat instances, and allow to attach/map them to URI and LB instances. What about adding/updating of webapps ? Is this a feature that will never be added ( because if it will be and it is not part of the design - then we're back to spaghetti ) Costin will probably mention JMX/CMX support, but I think this is something so important that it should be in HTTPD-dev and not only in mod_ajp. JMX is just a mean to an end. The goal is dynamic configuration ( i.e. without restart ). Yes, it should be more available in httpd-dev ( they do have some with .htaccess, etc ), but we have few clear use cases they don't. Well - dynamic add/remove of webapps is quite trivial in apache, you can add cgis/php/etc without restarting the server even today. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Mladen Turk wrote: Costin Manolache wrote: Mladen Turk wrote: Of course, no one is forced to participate in development, but everyone is welcome. The only question is do we have enough juice to make it official. AFICT, Remy, Henri and myself are in favor. But frankly I see no reason for someone to object, cause it's open source after all, and it doesn't break nothing that already exists. I'm not in favor, quite the contrary. And I thing there are reasons to object - "doesn't break anthing that exists" is not the only criteria used in apache. "Is it the best solution ?" can be used sometimes. I must disagree with you. There has been previous talks about 'wasting resources', that looks just like some corporate manager would talk. You can not stop people seeking other solutions, trying to build something better. It's the compete opposition of what IMO ASF stands for. At least in Apache httpd project - it seems they are not willing to accept solutions that "just work", they also try to find the best solution and take the long-term into account. If I make a design flaw, and the entire project gets unusable, it will make it just something like mod_java, mod_warp, mod_jk and mod_jk2 are... Dead. Nobody will get hanged for that. It's not as simple. Users will have to invest time in learning and setting up this new tool, etc. I don't think the goal is to accumulate more mod_warp, mod_jk, mod_jk2 - but to learn from the past errors and do something better. In any case - even if I'm no longer a very active tomcat committer, I think I can still -1 something that doesn't have a clear set of requirements, doesn't have a clear design that is able to support those features, doesn't have a configuration that is easy ( and by that I mean familiar for admins ), etc. You can ignore my vote if you want, but I'm pretty sure I am right. What about free spirit, and creative mess, that produced something like Apache2 and Tomcat. Are we going to need to have a full set of requirements and marketing analysis for each patch we make? Well, both Apache2 and Tomcat ( even tomcat3 ) had some design and requirements ( == goals ). And at least in apache2 I remember they did spent the time to discuss this and figure out the best design ( and quite a few "creative" solutions were not accepted ). Take a look at apache filters, or APR. This is not "just a patch" ( and even if it was - I think it's perfectly reasonable to think about the long-term goals on each patch - and not add features just because we can ). Usually spaghetti is the imediate result of accepting every feature. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mod_ajp initial
Graham Leggett wrote: > Mladen Turk wrote: > > > If I make a design flaw, and the entire project gets > unusable, it will > > make it just something like mod_java, mod_warp, mod_jk and > mod_jk2 are... Dead. > > Nobody will get hanged for that. > > Some code is always better than no code - at best, the code > will be good enough to fit the needs, and will end up in wide > use. At worst, the writers will say "we learned some lessons > from this" and try again. > True. A week or so before, none of us considered mod_proxy to be a good candidate for ajp protocol. The main reason was presumed 'closeness' of httpd developers to consider something like that. But, fortunately the discussion has led to something that might have a great potential. If we find enough support in httpd developers to accept the needed changes so we can build something usable and powerful enough to fulfill our (and presumably the users) needs, both mod_ajp and similar initiatives will be useless. There is also a question about 2.0 support, and that is the main reason for concerns. If all the changes made to make the mod_proxy 'ajp enabled' gets back propagated to 2.0 then we'll have all that is needed. Other option is to either write something from jk/jk2 in a short period of time (mod_ajp) that will fill in the gap of transition from 2.0 to 2.1, or still hanging around jk and jk2. In second case, I see the mod_ajp as a base for 2.0 users that will ease them to transition to mod_proxy in 2.1. That means that we will try to follow both the design and configuration look and feel the mod_proxy will use. And finally, when 2.1 gets the majority, the mod_ajp will be put in maintaining mode (read; shot to be dead :) MT. smime.p7s Description: S/MIME cryptographic signature
Re: Mod_ajp initial
Mladen Turk wrote: If I make a design flaw, and the entire project gets unusable, it will make it just something like mod_java, mod_warp, mod_jk and mod_jk2 are... Dead. Nobody will get hanged for that. Some code is always better than no code - at best, the code will be good enough to fit the needs, and will end up in wide use. At worst, the writers will say "we learned some lessons from this" and try again. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Mod_ajp initial
Henri Gomez wrote: Costin Manolache wrote: Mladen Turk wrote: Of course, no one is forced to participate in development, but everyone is welcome. The only question is do we have enough juice to make it official. AFICT, Remy, Henri and myself are in favor. But frankly I see no reason for someone to object, cause it's open source after all, and it doesn't break nothing that already exists. I'm not in favor, quite the contrary. And I thing there are reasons to object - "doesn't break anthing that exists" is not the only criteria used in apache. "Is it the best solution ?" can be used sometimes. Well I've got more than one reason to object to current jk2 and jk. jk works but the code is a huge spaghetti. jk2 didn't works well and we could consider it dead before it even reach production level. It's not a Henri/Mladen/Remy decision but what Apache admins says about jk2 here and outside ASF. I think mod_proxy + ajp + enhancements might be the right solution. It seems httpd people are willing to accept this into apache2, where it should be - and it seems very likely ( and reasonable ) they'll not accept another module that does almost the same thing ( but with different config and codebase ). Mladen has allready provided some update for HTTPD-DEV and I'm confident than Graham and Mladen will works together to improve mod_proxy to make in fine something as fast as the current mod_jk. I'm also not convinced that mod_ajp had been properly designed - I hear Henri mentioning "configurable non stop cluster" and "no restart", yet dynamic configuration was previously discarded by other people. And the config format suggests that little consideration was given to this - even the workers are configured in httpd.conf in a way that makes it hard to reconfigure with restarting apache. If dynamic reconfiguration ( even the minimal workers reconfig ) is on the list of features - adding it later will make the code as messy as mod_jk1 and 2. Well who said the Worker/Instance will have to be hardcoded in httpd.conf ? I said that some known Tomcat instances, Remy asked us to avoid the old jk/jk2 naming, are set in Apache 2 by default, but nothing prevent us to add new instance dynamically, via ajp_status or mod_status or whatever (may be even via AJP/1.4). And if "dynamic config" is not on the list - then it won't solve the problem for people who really need apache+tomcat, i.e. many large sites with uptime requirements. Why confuse the people with yet another connector - and what hope can we have it will not have the same fate as mod_webapp ? I'm handling sites requiring this kind of requirement and it's high on my mod_ajp features wish list. When you operate sites which works 24/24 and 7/7 and need to add horse power, it's a nightmare to have to wait some period in the night to make the Apache server update and restart. Also admins may want to add some power for a short period of time, so adding and removing such instances should be easy and quick. In any case - even if I'm no longer a very active tomcat committer, I think I can still -1 something that doesn't have a clear set of requirements, doesn't have a clear design that is able to support those features, doesn't have a configuration that is easy ( and by that I mean familiar for admins ), etc. You can ignore my vote if you want, but I'm pretty sure I am right. Well I'd like to resume the mod_ajp goal : - an APR/Apache 2 specific module (no more mess with #ifdef for 30 differents OS, we're in 2004). - extract ajp stuff and put it in an ajp library, which could be used outside within the Apache 2.0 module, used by proxy_ajp and of course in others applications, ie ajp-bench. - Study what has been done in mod_proxy to follow the start of art in Apache 2.x dev and make sure we could works with others AP2 modules. - Add/Remove/Update of Tomcat instances, and allow to attach/map them to URI and LB instances. Costin will probably mention JMX/CMX support, but I think this is something so important that it should be in HTTPD-dev and not only in mod_ajp. Thanks to comments We have noted that mod_proxy + mod_proxy_http are slow compared with mod_jk. I think that the next step should be to try to find "why" instead writting a new modules. May be a quick hacked mod_proxy_ajp to replace mod_proxy_http is the first step. Note that I am a bit reluctant to start a new module because I already had lost a lot of time in mod_webapp ;-( - 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: Mod_ajp initial
Costin Manolache wrote: Mladen Turk wrote: Of course, no one is forced to participate in development, but everyone is welcome. The only question is do we have enough juice to make it official. AFICT, Remy, Henri and myself are in favor. But frankly I see no reason for someone to object, cause it's open source after all, and it doesn't break nothing that already exists. I'm not in favor, quite the contrary. And I thing there are reasons to object - "doesn't break anthing that exists" is not the only criteria used in apache. "Is it the best solution ?" can be used sometimes. Well I've got more than one reason to object to current jk2 and jk. jk works but the code is a huge spaghetti. jk2 didn't works well and we could consider it dead before it even reach production level. It's not a Henri/Mladen/Remy decision but what Apache admins says about jk2 here and outside ASF. I think mod_proxy + ajp + enhancements might be the right solution. It seems httpd people are willing to accept this into apache2, where it should be - and it seems very likely ( and reasonable ) they'll not accept another module that does almost the same thing ( but with different config and codebase ). Mladen has allready provided some update for HTTPD-DEV and I'm confident than Graham and Mladen will works together to improve mod_proxy to make in fine something as fast as the current mod_jk. I'm also not convinced that mod_ajp had been properly designed - I hear Henri mentioning "configurable non stop cluster" and "no restart", yet dynamic configuration was previously discarded by other people. And the config format suggests that little consideration was given to this - even the workers are configured in httpd.conf in a way that makes it hard to reconfigure with restarting apache. If dynamic reconfiguration ( even the minimal workers reconfig ) is on the list of features - adding it later will make the code as messy as mod_jk1 and 2. Well who said the Worker/Instance will have to be hardcoded in httpd.conf ? I said that some known Tomcat instances, Remy asked us to avoid the old jk/jk2 naming, are set in Apache 2 by default, but nothing prevent us to add new instance dynamically, via ajp_status or mod_status or whatever (may be even via AJP/1.4). And if "dynamic config" is not on the list - then it won't solve the problem for people who really need apache+tomcat, i.e. many large sites with uptime requirements. Why confuse the people with yet another connector - and what hope can we have it will not have the same fate as mod_webapp ? I'm handling sites requiring this kind of requirement and it's high on my mod_ajp features wish list. When you operate sites which works 24/24 and 7/7 and need to add horse power, it's a nightmare to have to wait some period in the night to make the Apache server update and restart. Also admins may want to add some power for a short period of time, so adding and removing such instances should be easy and quick. In any case - even if I'm no longer a very active tomcat committer, I think I can still -1 something that doesn't have a clear set of requirements, doesn't have a clear design that is able to support those features, doesn't have a configuration that is easy ( and by that I mean familiar for admins ), etc. You can ignore my vote if you want, but I'm pretty sure I am right. Well I'd like to resume the mod_ajp goal : - an APR/Apache 2 specific module (no more mess with #ifdef for 30 differents OS, we're in 2004). - extract ajp stuff and put it in an ajp library, which could be used outside within the Apache 2.0 module, used by proxy_ajp and of course in others applications, ie ajp-bench. - Study what has been done in mod_proxy to follow the start of art in Apache 2.x dev and make sure we could works with others AP2 modules. - Add/Remove/Update of Tomcat instances, and allow to attach/map them to URI and LB instances. Costin will probably mention JMX/CMX support, but I think this is something so important that it should be in HTTPD-dev and not only in mod_ajp. Thanks to comments - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mod_ajp initial
Costin Manolache wrote: > > Mladen Turk wrote: > > > > Of course, no one is forced to participate in development, but > > everyone is welcome. > > The only question is do we have enough juice to make it official. > > AFICT, Remy, Henri and myself are in favor. > > But frankly I see no reason for someone to object, cause it's open > > source after all, and it doesn't break nothing that already exists. > > I'm not in favor, quite the contrary. > > And I thing there are reasons to object - "doesn't break > anthing that exists" is not the only criteria used in apache. > "Is it the best solution ?" can be used sometimes. > I must disagree with you. There has been previous talks about 'wasting resources', that looks just like some corporate manager would talk. You can not stop people seeking other solutions, trying to build something better. It's the compete opposition of what IMO ASF stands for. If I make a design flaw, and the entire project gets unusable, it will make it just something like mod_java, mod_warp, mod_jk and mod_jk2 are... Dead. Nobody will get hanged for that. > > In any case - even if I'm no longer a very active tomcat > committer, I think I can still -1 something that doesn't have > a clear set of requirements, doesn't have a clear design that > is able to support those features, doesn't have a > configuration that is easy ( and by that I mean familiar for > admins ), etc. You can ignore my vote if you want, but I'm > pretty sure I am right. > What about free spirit, and creative mess, that produced something like Apache2 and Tomcat. Are we going to need to have a full set of requirements and marketing analysis for each patch we make? Thing you've gone too far :( Regards, MT. smime.p7s Description: S/MIME cryptographic signature
Re: Mod_ajp initial
Mladen Turk wrote: Of course, no one is forced to participate in development, but everyone is welcome. The only question is do we have enough juice to make it official. AFICT, Remy, Henri and myself are in favor. But frankly I see no reason for someone to object, cause it's open source after all, and it doesn't break nothing that already exists. I'm not in favor, quite the contrary. And I thing there are reasons to object - "doesn't break anthing that exists" is not the only criteria used in apache. "Is it the best solution ?" can be used sometimes. I think mod_proxy + ajp + enhancements might be the right solution. It seems httpd people are willing to accept this into apache2, where it should be - and it seems very likely ( and reasonable ) they'll not accept another module that does almost the same thing ( but with different config and codebase ). I'm also not convinced that mod_ajp had been properly designed - I hear Henri mentioning "configurable non stop cluster" and "no restart", yet dynamic configuration was previously discarded by other people. And the config format suggests that little consideration was given to this - even the workers are configured in httpd.conf in a way that makes it hard to reconfigure with restarting apache. If dynamic reconfiguration ( even the minimal workers reconfig ) is on the list of features - adding it later will make the code as messy as mod_jk1 and 2. And if "dynamic config" is not on the list - then it won't solve the problem for people who really need apache+tomcat, i.e. many large sites with uptime requirements. Why confuse the people with yet another connector - and what hope can we have it will not have the same fate as mod_webapp ? In any case - even if I'm no longer a very active tomcat committer, I think I can still -1 something that doesn't have a clear set of requirements, doesn't have a clear design that is able to support those features, doesn't have a configuration that is easy ( and by that I mean familiar for admins ), etc. You can ignore my vote if you want, but I'm pretty sure I am right. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Graham Leggett wrote: Henri Gomez wrote: Peace on ASF :) Indeed :) well mod_ajp will probably goes a bit farther than mod_proxy + proxy_ajp since mod_proxy will allways relay static configuration, ie map some knowns URL to knowns Tomcat. Why would mod_proxy always rely on a static configuration? Don't forget that a lot of the features of mod_jk (the dynamic stuff especially) would be very much welcomed if they were added to the proxy framework. Don't think that the proxy code is cast in stone - it is not. The first patch for the scoreboard has already been contributed, and I'm waiting for a lack of objection, then the patch is going into httpd v2.1 with a vote for a backport to v2.0. Being able to dynamically configure backends other than just tomcat would be an extremely useful feature for people who use mod_perl, or CGI, or other application servers. Well Tomcat's commiters, I think we found another friend on HTTPD-DEV :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Henri Gomez wrote: Peace on ASF :) Indeed :) well mod_ajp will probably goes a bit farther than mod_proxy + proxy_ajp since mod_proxy will allways relay static configuration, ie map some knowns URL to knowns Tomcat. Why would mod_proxy always rely on a static configuration? Don't forget that a lot of the features of mod_jk (the dynamic stuff especially) would be very much welcomed if they were added to the proxy framework. Don't think that the proxy code is cast in stone - it is not. The first patch for the scoreboard has already been contributed, and I'm waiting for a lack of objection, then the patch is going into httpd v2.1 with a vote for a backport to v2.0. Being able to dynamically configure backends other than just tomcat would be an extremely useful feature for people who use mod_perl, or CGI, or other application servers. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Mod_ajp initial
Graham Leggett wrote: Remy Maucherat wrote: I think very few people are actually using mod_proxy instead of mod_jk. You've got to back your assertion with some kind of numbers, otherwise it's FUD. As do you. The assertion was based on comments on this mailing list, but we've already established that there is a need for the ajp protocol, lets move on. I disagree with your statements. Performance is first, as long as useability isn't too bad. Then we must agree to disagree. In my experience, if something isn't usable, it doesn't get used, so any potential performance advantage is purely theoretical. Lack of usability is one of the biggest failures in many open source projects, and I don't want to see httpd fall into that trap. Peace on ASF :) mod_jk is used on many productions sites. From my experience, admins who use jk are people who are experienced with Tomcat and as such trust jk and get habbits with its configuration. Admins using mod_proxy to link Apache to Tomcat are those who are more confortable with HTTPD standard modules. Up to Coyote, Tomcat HTTP stack was very slow and jk was mandatory for speed and stability. Now we have the choice even if jk is still faster than mod_proxy and proxy_http, but I'm sure than when proxy_http will be using HTTP connections pool the difference will be minimal. And I'm sure than Graham and others will boost mod_proxy+proxy_http :) To give an example, a mod_jk 1.2.x fully rewritten with APR, compiled with Apache, and with better configuration would clearly be useable enough (I think mod_jk 1.2 was actually good enough on many Unix platforms). It would be different to the established configuration method for backend servers, thus causing comments like "why does ajp work differently to the rest of the server", and "why is the load balancing feature of ajp not available server wide?". well mod_ajp will probably goes a bit farther than mod_proxy + proxy_ajp since mod_proxy will allways relay static configuration, ie map some knowns URL to knowns Tomcat. The next step is to be able to update URI Mapping and Tomcat defs in real, to avoid a restart of a production server. I know real productions case where the HTTPD server COULDN'T and SHOULDN'T be restarted and when you add another Tomcat to the cluster, for example to help support an increase of load. mod_ajp will help these admins to have a configurable non-stop cluster 'controller'. But for those without this requirement mod_proxy + proxy_ajp will be a perfect combination. I'm sure Mladen, Henri and Bill will look thoroughly at mod_proxy, and will try their best to use it, but you really need to relax your position from "-1 for your code if it doesn't use mod_proxy". You need to add "unless we find good reasons why it wouldn't work for us". httpd exists for the use of end users, not for the private use of just the people you listed. If somebody is going to the effort of creating a module specifically for httpd v2.0, then I don't see why they wouldn't go to the effort of making it fit into the established framework properly. Tomcat also exist for the use of end users. All ASF products are made for users, not for hackers purposes. Read my statement about dynamic configuration and you'll see it's something needed for admins. Part of my pay job is managing Apache HTTPD and Tomcat servers and the dynamic update is really something needed, because I don't want to see one day commercial products installed since Apache HTTPD and Tomcats couldn't sastify this need. Yes, as many here I'd want to use ASF products, for real productions situations, I'm not a hacker. I think _you_ need to do some research into mod_proxy, how it is designed and exactly how it works before making statements about it's performance. By testing the mod_proxy_http module, and then making statements about mod_proxy (a totally different module) shows that you don't know how the proxy framework works. We understand that mod_proxy is a kind of server in HTTPD, I also track new-httpd list and remember the mod_proxy genese, the pros and cons even in HTTPD commiters. Mladen, Graham, Bill, Henri, Remy, we're all ASF commiters and as such we should works together to make ASF products better. The only way is to learn from each others since there is also great commiters in jakarta. BTW, Mladen, who known very well Apache 2.0 allready send some comments, fixes and patches for mod_proxy and proxy_http. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Remy Maucherat wrote: I think very few people are actually using mod_proxy instead of mod_jk. You've got to back your assertion with some kind of numbers, otherwise it's FUD. As do you. The assertion was based on comments on this mailing list, but we've already established that there is a need for the ajp protocol, lets move on. I disagree with your statements. Performance is first, as long as useability isn't too bad. Then we must agree to disagree. In my experience, if something isn't usable, it doesn't get used, so any potential performance advantage is purely theoretical. Lack of usability is one of the biggest failures in many open source projects, and I don't want to see httpd fall into that trap. To give an example, a mod_jk 1.2.x fully rewritten with APR, compiled with Apache, and with better configuration would clearly be useable enough (I think mod_jk 1.2 was actually good enough on many Unix platforms). It would be different to the established configuration method for backend servers, thus causing comments like "why does ajp work differently to the rest of the server", and "why is the load balancing feature of ajp not available server wide?". I'm sure Mladen, Henri and Bill will look thoroughly at mod_proxy, and will try their best to use it, but you really need to relax your position from "-1 for your code if it doesn't use mod_proxy". You need to add "unless we find good reasons why it wouldn't work for us". httpd exists for the use of end users, not for the private use of just the people you listed. If somebody is going to the effort of creating a module specifically for httpd v2.0, then I don't see why they wouldn't go to the effort of making it fit into the established framework properly. I think _you_ need to do some research into mod_proxy, how it is designed and exactly how it works before making statements about it's performance. By testing the mod_proxy_http module, and then making statements about mod_proxy (a totally different module) shows that you don't know how the proxy framework works. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Mod_ajp initial
Graham Leggett wrote: Remy Maucherat wrote: The framework itself could be designed in a way which would end up hurting performance. It did happen in Tomcat in the past, and I don't know about mod_proxy since I haven't looked at it, but it could happen. All the framework does is determine that a proxy handler is responsible for servicing the request, and passes control to that proxy handler. Any performance problem will be proxy_ajp's problem. I think you should be more open minded about a possible mod_ajp connector This isn't about being "open minded", it's about being consistent through the design of httpd. One of the most important features of mod_ajp, even more important than performance, is usability. If the configuration of mod_ajp is significantly different from the configration of proxy, it just adds confusion to end users. mod_jk is already way too complex to be useful - which is why people are choosing proxy_http over mod_jk, even if mod_jk is faster. I think very few people are actually using mod_proxy instead of mod_jk. You've got to back your assertion with some kind of numbers, otherwise it's FUD. I disagree with your statements. Performance is first, as long as useability isn't too bad. To give an example, a mod_jk 1.2.x fully rewritten with APR, compiled with Apache, and with better configuration would clearly be useable enough (I think mod_jk 1.2 was actually good enough on many Unix platforms). I'm sure Mladen, Henri and Bill will look thoroughly at mod_proxy, and will try their best to use it, but you really need to relax your position from "-1 for your code if it doesn't use mod_proxy". You need to add "unless we find good reasons why it wouldn't work for us". Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Remy Maucherat wrote: The framework itself could be designed in a way which would end up hurting performance. It did happen in Tomcat in the past, and I don't know about mod_proxy since I haven't looked at it, but it could happen. All the framework does is determine that a proxy handler is responsible for servicing the request, and passes control to that proxy handler. Any performance problem will be proxy_ajp's problem. I think you should be more open minded about a possible mod_ajp connector This isn't about being "open minded", it's about being consistent through the design of httpd. One of the most important features of mod_ajp, even more important than performance, is usability. If the configuration of mod_ajp is significantly different from the configration of proxy, it just adds confusion to end users. mod_jk is already way too complex to be useful - which is why people are choosing proxy_http over mod_jk, even if mod_jk is faster. On the other side of the fence, we have yet to find out that mod_proxy will fully fit our needs. Then I suggest looking at the mod_proxy source, and learning how it works. This will clear up the apparent confusion that exists between mod_proxy and proxy_http. The key functions are proxy_handler() and the proxy_run_scheme_handler() hook. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
RE: Mod_ajp initial
Henri Gomez wrote: > Bill Barker wrote: > > > I'm with Graham on this. Personally, I have very little > interest in a > > mod_ajp module, but I am interested in proxy_ajp, proxy_lb, > etc. Of > > course, since j-t-c has long doubled as j-t-sandbox, this > means that > > I'm +0 for committing your stuff there. > > Well Mladen has been quick to release this initial work and I > suspect it will be faster again to make a valid prototype. > Sure thing :-). > Now we should know who could works on it ? > Of course, no one is forced to participate in development, but everyone is welcome. The only question is do we have enough juice to make it official. AFICT, Remy, Henri and myself are in favor. But frankly I see no reason for someone to object, cause it's open source after all, and it doesn't break nothing that already exists. It will of course produce a lot of reusable code for any preferred framework, that can only be a benefit in long run. Simply speaking we will only have a jk/jk2 functionality in a full-blown optimized Apache2 module. MT. smime.p7s Description: S/MIME cryptographic signature
Re: Mod_ajp initial
Bill Barker wrote: I'm with Graham on this. Personally, I have very little interest in a mod_ajp module, but I am interested in proxy_ajp, proxy_lb, etc. Of course, since j-t-c has long doubled as j-t-sandbox, this means that I'm +0 for committing your stuff there. Well Mladen has been quick to release this initial work and I suspect it will be faster again to make a valid prototype. Now we should know who could works on it ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Remy Maucherat wrote: Graham Leggett wrote: Remy Maucherat wrote: Until I'm shown a mod_proxy (with HTTP) with performance close to mod_jk, my opinion is that we can't use it. As I've pointed out already, mod_proxy is a framework. The performance numbers quoted tested mod_proxy_http, not mod_proxy, which doesn't do anything on it's own. There is no reason why proxy_ajp would be any slower than mod_ajp. The framework itself could be designed in a way which would end up hurting performance. It did happen in Tomcat in the past, and I don't know about mod_proxy since I haven't looked at it, but it could happen. I think you should be more open minded about a possible mod_ajp connector (assuming it ends up being a quality connector), and block it on principle. On the other side of the fence, we have yet to find out that mod_proxy will fully fit our needs. Well I think that we should consider mod_ajp as a jk rewriting for Apache 2.0 (2.1) using all APR/APACHE2.x power. Since we plan to developp an AJP library, it will ease the task for ajp_proxy and we could validate many points like this and have a release rate independant from the HTTPD 2.0/2.1 rr. Of course mod_proxy will be extended by Graham and I'm sure he'll put more and more optimisation in it, giving a better proxy framework to HTTPD 2.x. And when ajp_proxy will be ASF production level ready, it could be included in HTTPD tree. After that we could probably stop mod_ajp or use it as a features labs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Graham Leggett wrote: Remy Maucherat wrote: Until I'm shown a mod_proxy (with HTTP) with performance close to mod_jk, my opinion is that we can't use it. As I've pointed out already, mod_proxy is a framework. The performance numbers quoted tested mod_proxy_http, not mod_proxy, which doesn't do anything on it's own. There is no reason why proxy_ajp would be any slower than mod_ajp. The framework itself could be designed in a way which would end up hurting performance. It did happen in Tomcat in the past, and I don't know about mod_proxy since I haven't looked at it, but it could happen. I think you should be more open minded about a possible mod_ajp connector (assuming it ends up being a quality connector), and block it on principle. On the other side of the fence, we have yet to find out that mod_proxy will fully fit our needs. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
Remy Maucherat wrote: Until I'm shown a mod_proxy (with HTTP) with performance close to mod_jk, my opinion is that we can't use it. As I've pointed out already, mod_proxy is a framework. The performance numbers quoted tested mod_proxy_http, not mod_proxy, which doesn't do anything on it's own. There is no reason why proxy_ajp would be any slower than mod_ajp. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Mod_ajp initial
Bill Barker wrote: I'm with Graham on this. Personally, I have very little interest in a mod_ajp module, but I am interested in proxy_ajp, proxy_lb, etc. Of course, since j-t-c has long doubled as j-t-sandbox, this means that I'm +0 for committing your stuff there. I think Mladen's initiative is very good. Until I'm shown a mod_proxy (with HTTP) with performance close to mod_jk, my opinion is that we can't use it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_ajp initial
I'm with Graham on this. Personally, I have very little interest in a mod_ajp module, but I am interested in proxy_ajp, proxy_lb, etc. Of course, since j-t-c has long doubled as j-t-sandbox, this means that I'm +0 for committing your stuff there. - Original Message - From: "Graham Leggett" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Sunday, July 25, 2004 9:58 AM Subject: Re: Mod_ajp initial > Mladen Turk wrote: > > > Yes, that's the general idea. > > We focus on v2.0 and TCP/IP protocol (for now). > > Cool. > > > Well, the development will not be over in 2 days, and the plan is to use > > mod_ajp as a base for testing new protocol extensions, and to be always a > > little bit faster and better then mod_proxy with proxy_ajp :). > > Don't forget mod_proxy is just a framework - there would be no "faster > than proxy_ajp" because prioxy_ajp would be mod_ajp with config > directives arranged differently. > > Remember that the benchmarks that were done recently compared mod_ajp > with mod_proxy_http, not mod_proxy. As is clear from the benchmarks, > mod_proxy_http could benefit greatly from a connection cache for a > start. If that connection cache were protocol neutral, then > mod_proxy_ftp could benefit from the connection pool too. > > > The mod_proxy itself will have to face a lot of extra work too. > > Exactly - which is why I'm dead keen to have the AJP work aligned with > proxy, so that proxy can benefit from AJP features like load balancing, etc. > > > It will at least have to have a maintainable set of connection pools for > > each backend server, so one can implement a load balancer from them, and > > also control the number of connections the backend can handle. > > mod_core will need an extra work too, so that the scoreboard can be extended > > to store the lb params. This is essential if one wishes to have a load > > balancer. > > > > If you succeed to build such a feature for mod_proxy and http protocol, then > > we will already have a ready proxy_ajp protocol extension. > > From the sounds of things, many of these features exist (or will soon > exist) in mod_ajp. Moving or copying these features out of mod_ajp and > into either mod_proxy* or any of the core modules isn't a difficult > thing to do. If you create patches that you need for either proxy or the > core to support stuff that you need, I'll make sure they get into httpd > v2.1 with support for inclusion into httpd v2.0. > > Regards, > Graham > -- > This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mod_ajp initial
Graham Leggett wrote: > > Well, the development will not be over in 2 days, and the > plan is to > > use mod_ajp as a base for testing new protocol extensions, > and to be > > always a little bit faster and better then mod_proxy with > proxy_ajp :). > > Don't forget mod_proxy is just a framework - there would be > no "faster than proxy_ajp" because prioxy_ajp would be > mod_ajp with config directives arranged differently. > True, but we will still have a framework that existing jk/jk2 will find easy to handle. It will also be a framework for testing protocols and protocol layers, and we will not need to wait for a official release for bugfixes. Once when proxy_ajp will be operational and stable we will move mod_ajp to other direction probably adding jmx and autodiscovery, that is mostly TC related and dependant, so the work will not be wasted, thought, with possible support for inclusion in proxy_ajp :). > > > The mod_proxy itself will have to face a lot of extra work too. > > Exactly - which is why I'm dead keen to have the AJP work > aligned with proxy, so that proxy can benefit from AJP > features like load balancing, etc. > Sure, we will work on proxy (I can speak only for myself), but... Well, except j-f-c none of us has a commit privilege to httpd tree, so how do you suppose that the development can take a place after all? > > > > If you succeed to build such a feature for mod_proxy and http > > protocol, then we will already have a ready proxy_ajp > protocol extension. > > From the sounds of things, many of these features exist (or will soon > exist) in mod_ajp. Moving or copying these features out of > mod_ajp and into either mod_proxy* or any of the core modules > isn't a difficult thing to do. If you create patches that you > need for either proxy or the core to support stuff that you > need, I'll make sure they get into httpd > v2.1 with support for inclusion into httpd v2.0. > Cool, The first thing I will do is a extendable scoreboard, so that the module can exchange params among child process. The loadbalancer will use that to calculate the scores for each lb instance. I rewrote a workable solution for that in jk2 using apr, so it shouldn't be a big deal. Exactly the same scoreboard will be in mod_ajp, so once you commit something to 2.1 core, we will drop our own. MT. smime.p7s Description: S/MIME cryptographic signature
Re: Mod_ajp initial
Mladen Turk wrote: Yes, that's the general idea. We focus on v2.0 and TCP/IP protocol (for now). Cool. Well, the development will not be over in 2 days, and the plan is to use mod_ajp as a base for testing new protocol extensions, and to be always a little bit faster and better then mod_proxy with proxy_ajp :). Don't forget mod_proxy is just a framework - there would be no "faster than proxy_ajp" because prioxy_ajp would be mod_ajp with config directives arranged differently. Remember that the benchmarks that were done recently compared mod_ajp with mod_proxy_http, not mod_proxy. As is clear from the benchmarks, mod_proxy_http could benefit greatly from a connection cache for a start. If that connection cache were protocol neutral, then mod_proxy_ftp could benefit from the connection pool too. The mod_proxy itself will have to face a lot of extra work too. Exactly - which is why I'm dead keen to have the AJP work aligned with proxy, so that proxy can benefit from AJP features like load balancing, etc. It will at least have to have a maintainable set of connection pools for each backend server, so one can implement a load balancer from them, and also control the number of connections the backend can handle. mod_core will need an extra work too, so that the scoreboard can be extended to store the lb params. This is essential if one wishes to have a load balancer. If you succeed to build such a feature for mod_proxy and http protocol, then we will already have a ready proxy_ajp protocol extension. From the sounds of things, many of these features exist (or will soon exist) in mod_ajp. Moving or copying these features out of mod_ajp and into either mod_proxy* or any of the core modules isn't a difficult thing to do. If you create patches that you need for either proxy or the core to support stuff that you need, I'll make sure they get into httpd v2.1 with support for inclusion into httpd v2.0. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
RE: Mod_ajp initial
Graham Leggett wrote: > > Mladen Turk wrote: > > > Some rationale: > > > > I spoke with Henri and we decided that although mod_proxy with > > proxy_ajp is a good idea (in the long term... very long > term), we need > > something that will fill in the gaps. > > As there is an existing codebase, getting a module together > that supports Apache v2.0 natively is a good start to clean > up the module and get it aligned with how Apache v2.0 works. > Yes, that's the general idea. We focus on v2.0 and TCP/IP protocol (for now). > I however will be -1 on the eventual formal inclusion of the > module into httpd natively until it supports the proxy > framework. Well, the development will not be over in 2 days, and the plan is to use mod_ajp as a base for testing new protocol extensions, and to be always a little bit faster and better then mod_proxy with proxy_ajp :). > A significant amount of work has been done in > httpd to ensure that proxy functionality (such as cache) is > available to as wide an audience of users as possible. Adding > a module that neither conforms to the established framework > inside httpd, or offers it's functionality to protocols > outside of AJP I believe is a step backwards for httpd. > The mod_proxy itself will have to face a lot of extra work too. It will at least have to have a maintainable set of connection pools for each backend server, so one can implement a load balancer from them, and also control the number of connections the backend can handle. mod_core will need an extra work too, so that the scoreboard can be extended to store the lb params. This is essential if one wishes to have a load balancer. If you succeed to build such a feature for mod_proxy and http protocol, then we will already have a ready proxy_ajp protocol extension. MT. smime.p7s Description: S/MIME cryptographic signature
Re: Mod_ajp initial
Mladen Turk wrote: Some rationale: I spoke with Henri and we decided that although mod_proxy with proxy_ajp is a good idea (in the long term... very long term), we need something that will fill in the gaps. As there is an existing codebase, getting a module together that supports Apache v2.0 natively is a good start to clean up the module and get it aligned with how Apache v2.0 works. I however will be -1 on the eventual formal inclusion of the module into httpd natively until it supports the proxy framework. A significant amount of work has been done in httpd to ensure that proxy functionality (such as cache) is available to as wide an audience of users as possible. Adding a module that neither conforms to the established framework inside httpd, or offers it's functionality to protocols outside of AJP I believe is a step backwards for httpd. That being said, all work on mod_ajp to get it aligned with httpd v2.0 is a step in the right direction as it makes it easier in the long term to create separate modules for features such as load balancing, etc, and eventually get the module aligned so that it fits into the mod_proxy framework. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Mod_ajp initial
Hi all, To whom it may satisfy... Here is some code that can be used for starting mod_ajp for Apache2.0/2.1. You are welcome to join :) It can be downloaded from: http://www.apache.org/~mturk/modajp.tar.gz Some rationale: I spoke with Henri and we decided that although mod_proxy with proxy_ajp is a good idea (in the long term... very long term), we need something that will fill in the gaps. The code dealing with communication using sockets will be from jk/jk2 as well as AJP protocol. Also, in the next version it will support AJP13+ or AJP14 protocol extensions including simple crypto and compression to either secure or lower the bandwidth of the transportation channel, together with service channels for basic lb statuses and typical 'going-down-[in xxx seconds]-do-not-accept-any-new-sessions' sittuations (not sure about autodiscovery). The code itself has only implemented configuration, uri matching, and a simple hanlder just displaying selected worker/balancer. Here is how the httpd.config looks after: LoadModule ajp_module modules/mod_ajp.so AjpHost localhost:8009 AjpLbFactor 30 AjpHost otherhost:8009 AjpHost thirdhost AjpPort 8009 AjpLbFactor AjpWorkerAdd ajp1 AjpWorkerAdd ajp3:30 AjpStickySession On AjpWorkerAdd ajp2 AjpWorkerAdd ajp3:70 AjpStickySession On About Worker: Worker is a cnnector to remote TC instance. It maintains a connection socket pool (mix...max), with configurable cleanup time for extra max-min sockets. All the configurable socket params from jk/jk2 are implemented, like keep-alive, timeout, etc... About LoadBalancer: Each LoadBalancer maintains It's own lb status for each worker, so that you can have different lb schemes for same workers (the thing I was looking to implement in jk2, but it would require too much coding). It basically enables that workerA in lbA works on 30% load while the same workerA in lbB works with 50% load, etc... Also the LbFactors are in percentages (finally), and also normalized on post_config, meaning that if you don't specify the lbfactor it will get computed, counting already set factors, so that the sum of all factors in particular lb is 100. The sticky session does not need to be 'jsessionid', but can rather be configurable, perhaps with 'jvmroute'. Just use 'AjpStickySession jvmroute' directive. It has also the AjpStickySessionForce On|Off, that returns 503 when worker is bussy or down actually enabling or disabling failover if there is no session replication on backend servers. Uri Mappings: There are four directives for uri mappings with different scenarios. 'AjpMount /examples lba' behaves just like JkMount, Or you can: AjpMount lba There is also AjpNoMount directive that behaves like the name implies. AjpMount lba AjpNoMount *.gif Each of them has Match extension that uses regular expression AjpMount lba AjpNoMountMatch \.gif$ If the directives are used inside server root they are considered 'global' and are potentially propagated to each virtual host if you specify: 'AjpOptions Inherit' directive. You can at any time use 'AjpOptions -Inherit' to suppress further inheritance. So you can: AjpOptions Inherit AjpMount *.jsp lba And each vhost will have the registered *.jsp going trough lba worker. Also, all directives inside SetHandler ajp-info and can be used to display other non-runtime infos like uri mappings, etc... If we need that after all. List of all implemented directives: smime.p7s Description: S/MIME cryptographic signature
