Re: [proxy] New implementation ready for testing
Graham Leggett wrote: Mladen Turk wrote: Since we are (Henri and myself, not sure for JeanFrederic) not httpd commiters, I'm not sure how the proxy_ajp will get maintained, but we can always send patches :) I'm quite happy to maintain the code, and can chase up any patches you send through in the mean time, if others don't beat me to it. Well I certainly will continue to support at least the ajp13 protocol in jakarta-tomcat-connector :)
Re: [proxy] New implementation ready for testing
On 11 Aug 2004, at 17:14, Mladen Turk wrote:
Hi all,
We've finished the initial development of extended mod_proxy.
Since the development took place at jakata-tomcat-connectors,
the source code can be found under ajp/proxy.
Here is the list of major features added:
3. Added new module proxy_balancer
What's wrong with:
ProxyPassReverse / http://localhost:/
ProxyPreserveHost On
RewriteMap hosts rnd:/opt/apache/conf/tables/hosts.map
RewriteRule ^/(.*) ${hosts:live}/$1 [P,L]
It's in there already, and it works great (I even have a couple of CGIs
reading and building up that table, enabling, disabling and
prioritizing hosts).
http://wiki.apache.org/cocoon/ApacheModProxy
http://wiki.apache.org/cocoon/LoadBalancingWithModProxy
Pier
smime.p7s
Description: S/MIME cryptographic signature
Re: [proxy] New implementation ready for testing
Pier Fumagalli wrote:
On 11 Aug 2004, at 17:14, Mladen Turk wrote:
Hi all,
We've finished the initial development of extended mod_proxy.
Since the development took place at jakata-tomcat-connectors,
the source code can be found under ajp/proxy.
Here is the list of major features added:
3. Added new module proxy_balancer
What's wrong with:
- http is slower than ajp (Therefore the idea of mod_proxy_ajp).
- failover.
Cheers
Jean-Frederic
ProxyPassReverse / http://localhost:/
ProxyPreserveHost On
RewriteMap hosts rnd:/opt/apache/conf/tables/hosts.map
RewriteRule ^/(.*) ${hosts:live}/$1 [P,L]
It's in there already, and it works great (I even have a couple of CGIs
reading and building up that table, enabling, disabling and prioritizing
hosts).
http://wiki.apache.org/cocoon/ApacheModProxy
http://wiki.apache.org/cocoon/LoadBalancingWithModProxy
Pier
Re: [proxy] New implementation ready for testing
On Aug 16, 2004, at 6:54 AM, Pier Fumagalli wrote:
On 11 Aug 2004, at 17:14, Mladen Turk wrote:
Hi all,
We've finished the initial development of extended mod_proxy.
Since the development took place at jakata-tomcat-connectors,
the source code can be found under ajp/proxy.
Here is the list of major features added:
3. Added new module proxy_balancer
What's wrong with:
ProxyPassReverse / http://localhost:/
ProxyPreserveHost On
RewriteMap hosts rnd:/opt/apache/conf/tables/hosts.map
RewriteRule ^/(.*) ${hosts:live}/$1 [P,L]
It's in there already, and it works great (I even have a couple of
CGIs reading and building up that table, enabling, disabling and
prioritizing hosts).
http://wiki.apache.org/cocoon/ApacheModProxy
http://wiki.apache.org/cocoon/LoadBalancingWithModProxy
Having a human weigh or prioritize hosts may work well in a small
environment, but it is too much to manage in a large one. Besides,
while random selection is a decent algorithm under certain
circumstances, mod_proxy lacks the insight into the global state of
resources to make truly intelligent resource-based allocation
decisions.
I haven't had the time lately, but you (all) are welcome to dissect the
mod_backhand (Apache 1.3) module and pull the resource collection and
decision making framework out and put in into mod_proxy for Apache 2.
The algorithms therein are flexible, proven and even extensible. We
have seen several large architectures use m_b with great success in
front of even ISS servers and Java application servers of all types.
http://www.backhand.org/mod_backhand/
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
// Ecelerity: fastest MTA on Earth
Re: [proxy] New implementation ready for testing
Pier Fumagalli wrote:
What's wrong with:
ProxyPassReverse / http://localhost:/
ProxyPreserveHost On
RewriteMap hosts rnd:/opt/apache/conf/tables/hosts.map
RewriteRule ^/(.*) ${hosts:live}/$1 [P,L]
It isn't very elegant though. Someone who is well versed in mod_rewrite
and regular expressions might find it really easy, but the rest of us
mortals won't. :(
Regards,
Graham
--
Re: [proxy] New implementation ready for testing
I've been following the changes to mod_proxy and have been absolutely
estatic as to where everything is headed and what is being done. I've been
working with a very large client for two years changing their whole
architectuer and using an Apache front end employing mod_proxy to their
backend technologies, which is just about everything under the sun.
I have a few comments on the direction this thread is following. Some may
be more to my ignorance as I've only been looking at these threads deeply
for the past two weeks (as the client is finally convinced to move to
apache 2 from the 1.3 series).
The first one is this method as prescribed above does not seem to have a
failover mechanism, i.e. if connection to one server fails, then the next
in line is tried. This is quite important for mission critical
installations.
The second is that while pure randomness is better than nothing, some
weighting system has significant advantages. The first one, from my
perspective, is the ability to define a back end primary and secondary
service. For example, if I could weight one server at 100 and another at
0, then the primary server would always be called, unless it went down and
then the secondary server would be called.
While tying this all in with mod backhand is good as suggested, perhaps
even simpler would be a least connections test. I'm deploying an Alteon
front end to the Apache web server for the client, and wghen investigating
all the options available for load balancing, least connections definitely
won out. In thecase of connecting to a back end app server I can see where
it is not as good, but is relatively simple to implement. I suppose it
would also have to be least active connections if the connection pooling
gets done.
Another consideration for the future is handling all of this when you are
running mutliple servers with Apache up front in a load balanced
enviornment. I am currently deploying an IBM blade center which
equivelantly is 14 PC's sharing some common resources, but not memory.
Whether in load balancing or connection pooling it would be nice to have
some level of communication between the blades to ensure the system runs
more smoothly.
Lastly, iI feel if I am going to make some recommendations, I should
contribute something back. While I am not comfortable with the time I have
available to help with coding, I can easily commit to some testing and
verification time as soon as I have my test blade center up.
Cheers, and thanks for the good work everyone.
Jeffrey Burgoyne
Chief Technology Architect
KCSI Keenuh Consulting Services Inc
[EMAIL PROTECTED]
On Mon, 16 Aug 2004, Graham Leggett wrote:
Pier Fumagalli wrote:
What's wrong with:
ProxyPassReverse / http://localhost:/
ProxyPreserveHost On
RewriteMap hosts rnd:/opt/apache/conf/tables/hosts.map
RewriteRule ^/(.*) ${hosts:live}/$1 [P,L]
It isn't very elegant though. Someone who is well versed in mod_rewrite
and regular expressions might find it really easy, but the rest of us
mortals won't. :(
Regards,
Graham
--
Re: [proxy] New implementation ready for testing
On 16 Aug 2004, at 12:49, jean-frederic clere wrote: Pier Fumagalli wrote: On 11 Aug 2004, at 17:14, Mladen Turk wrote: Hi all, We've finished the initial development of extended mod_proxy. Since the development took place at jakata-tomcat-connectors, the source code can be found under ajp/proxy. Here is the list of major features added: 3. Added new module proxy_balancer What's wrong with: - http is slower than ajp (Therefore the idea of mod_proxy_ajp). Although I don't agree in the AJP protocol, I see the point... - failover. That's a good point! :-P +1 Pier smime.p7s Description: S/MIME cryptographic signature
Re: [proxy] New implementation ready for testing
Jeffrey Burgoyne wrote: The first one is this method as prescribed above does not seem to have a failover mechanism, i.e. if connection to one server fails, then the next in line is tried. This is quite important for mission critical installations. The second is that while pure randomness is better than nothing, some weighting system has significant advantages. The first one, from my perspective, is the ability to define a back end primary and secondary service. For example, if I could weight one server at 100 and another at 0, then the primary server would always be called, unless it went down and then the secondary server would be called. In theory the proxy balancer should do the above for you. Can you give the new httpd v2.1 proxy code a test to see if it works? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: [proxy] New implementation ready for testing
Theo Schlossnagle wrote: I haven't had the time lately, but you (all) are welcome to dissect the mod_backhand (Apache 1.3) module and pull the resource collection and decision making framework out and put in into mod_proxy for Apache 2. I have been watching the commits to proxy, but haven't yet had time to go into them in detail yet, so this may or may not be already possible: The balancer module should be replaceable, so if you had a java application server backend the current balancer with session stickiness would probably work for you. Then in other environments, one of the mod_backhand components could be switched in to have balancing work entirely differently. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: [proxy] New implementation ready for testing
I plan on doing a pretty thourough test as soon as I get access to the box we will be using. Currently our network specialists are working to get the front end Alteon load balancers working properly. We've been hampered by a number of linux network issues that may yet take some time to resolve. Jeffrey Burgoyne Chief Technology Architect KCSI Keenuh Consulting Services Inc [EMAIL PROTECTED] On Mon, 16 Aug 2004, Graham Leggett wrote: Jeffrey Burgoyne wrote: The first one is this method as prescribed above does not seem to have a failover mechanism, i.e. if connection to one server fails, then the next in line is tried. This is quite important for mission critical installations. The second is that while pure randomness is better than nothing, some weighting system has significant advantages. The first one, from my perspective, is the ability to define a back end primary and secondary service. For example, if I could weight one server at 100 and another at 0, then the primary server would always be called, unless it went down and then the secondary server would be called. In theory the proxy balancer should do the above for you. Can you give the new httpd v2.1 proxy code a test to see if it works? Regards, Graham --
[proxy] New implementation ready for testing
Hi all, We've finished the initial development of extended mod_proxy. Since the development took place at jakata-tomcat-connectors, the source code can be found under ajp/proxy. Here is the list of major features added: 1. AJP13 protocol support 2. Connection pool for threaded servers 3. Added new module proxy_balancer 4. Added mod_status extended information hook. Connection pool: The connection pool enables reusing backend connections and was build around apr_reslist. At the moment only the proxy_ajp extensively uses this connection pool, with performance slightly better then mod_jk. Http module also uses connection pool, but only to the level of skipping DNS lookup, and shows around 20% performance boost over the current implementation. Ftp module although uses the connection pool will need more testing. proxy_balancer: The new proxy balancer is capable to balance the load trough the cluster of backend server. For the moment the implemented algorithm is based on the preset dispatch factor, counting the number of connections processed on each node. It can mix the protocols so one can make a cluster containing the http, ajp and ftp backends, although the usability of such configuration is questionable. TODO: 1. Testing 2. Bugfixing 3. finish AJP13 (ssl + resend) P.S. I'll be on vacation for the next two weeks, and unreachable by the standard electronic devices. Regards, MT. smime.p7s Description: S/MIME Cryptographic Signature
Re: [proxy] New implementation ready for testing
At 11:14 AM 8/11/2004, Mladen Turk wrote: We've finished the initial development of extended mod_proxy. Since the development took place at jakata-tomcat-connectors, the source code can be found under ajp/proxy. That's something of a shame, because we lose the development history importing the finished effort, and it was further disappointing that you didn't bring across the earlier cvs history so this branch could be brought back into httpd/modules/proxy with a complete history. I'm actually very excited that we can offer in the 2.2 release - this really rocks. What you accomplished is very cool! I'm entirely +1 today for bringing it back into modules/proxy/ (it's a c-t-r branch.) How you did it makes this a non-trivial exercise. Boo :( (Sorry my earlier responses only seem to have hit httpd-dev, due to trashcan'ned moderation and my list-receipt email differing from my -accept from account differing.) Bill
Re: [proxy] New implementation ready for testing
At 11:14 AM 8/11/2004, Mladen Turk wrote: The connection pool enables reusing backend connections and was build around apr_reslist. At the moment only the proxy_ajp extensively uses this connection pool, with performance slightly better then mod_jk. I noticed one huge win - unless I'm misreading... we don't require any includes from j2sdk/include/ ??? That in and of itself is great :) Bill
Re: [proxy] New implementation ready for testing
William A. Rowe, Jr. wrote: We've finished the initial development of extended mod_proxy. Since the development took place at jakata-tomcat-connectors, the source code can be found under ajp/proxy. I'm entirely +1 today for bringing it back into modules/proxy/ (it's a c-t-r branch.) How you did it makes this a non-trivial exercise. Boo :( Mea culpa :( Never cross my mind that we'll need all those try-error-fix commits back on the httpd cvs tree. Regards, MT. smime.p7s Description: S/MIME Cryptographic Signature
Re: [proxy] New implementation ready for testing
William A. Rowe, Jr. wrote: That's something of a shame, because we lose the development history importing the finished effort, and it was further disappointing that you didn't bring across the earlier cvs history so this branch could be brought back into httpd/modules/proxy with a complete history. Ideally though I personally would like to see proxy_ajp in httpd v2.0 (assuming it's practical, which could only be assessed once proxy_ajp existed). Getting it into a working form first, then getting it into v2.1, and then backporting it in clean logical sections to http v2.0 means it may be possible to get it into httpd v2.0, without small bugfix commits getting in the way. I'm actually very excited that we can offer in the 2.2 release - this really rocks. What you accomplished is very cool! I'm entirely +1 today for bringing it back into modules/proxy/ (it's a c-t-r branch.) How you did it makes this a non-trivial exercise. Boo :( My plan is to start bringing it into httpd v2.1 from next week, assessing how hard the backports to httpd v2.0 would potentially be. Is the history kept in the tomcat connector tree enough, or is it critical to get the full history into httpd HEAD? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: [proxy] New implementation ready for testing
Graham Leggett wrote: William A. Rowe, Jr. wrote: I'm actually very excited that we can offer in the 2.2 release - this really rocks. What you accomplished is very cool! I'm entirely +1 today for bringing it back into modules/proxy/ (it's a c-t-r branch.) How you did it makes this a non-trivial exercise. Boo :( My plan is to start bringing it into httpd v2.1 from next week, assessing how hard the backports to httpd v2.0 would potentially be. Is the history kept in the tomcat connector tree enough, or is it critical to get the full history into httpd HEAD? The sources in the ajp/proxy already have all thats needed for backporting. I'm actually using 2.0.50 for testing (with scoreboard patch), although it works and without that patc, only the balancer in that case convolves to the correct behavior statistically. Regards, MT. smime.p7s Description: S/MIME Cryptographic Signature
Re: [proxy] New implementation ready for testing
At 12:54 PM 8/11/2004, you wrote: Never cross my mind that we'll need all those try-error-fix commits back on the httpd cvs tree. We actually like those - the next individual to say wow - this fix is easy! can go back over history and say grumf - they tried that in the first place :) Question... ajp_header.lo ajp_link.lo ajp_msg.lo are all required by proxy_ajp - any thoughts on how those will be kept in-sync or what folks should do to obtain? Bill
Re: [proxy] New implementation ready for testing
At 01:03 PM 8/11/2004, Graham Leggett wrote: William A. Rowe, Jr. wrote: That's something of a shame, because we lose the development history importing the finished effort, and it was further disappointing that you didn't bring across the earlier cvs history so this branch could be brought back into httpd/modules/proxy with a complete history. Ideally though I personally would like to see proxy_ajp in httpd v2.0 (assuming it's practical, which could only be assessed once proxy_ajp existed). Getting it into a working form first, then getting it into v2.1, and then backporting it in clean logical sections to http v2.0 means it may be possible to get it into httpd v2.0, without small bugfix commits getting in the way. Since it will take some time to assess that the changes and new features are stable, v.s. dev quality, I believe it's sorta pointless to put extra energy into the 2.0 backport. We won't compromise mod_proxy again in 2.0 after its very slow crawl to some measure of stability. So count me a pretty strong -1 for backporting any major refactoring of proxy for 2.0. You know what pain it took for proxy to be accepted as useful (v.s. 1.3). This is a pretty significant leap, so it really doesn't make that much sense to compromise things. I'm actually very excited that we can offer in the 2.2 release - this really rocks. What you accomplished is very cool! I'm entirely +1 today for bringing it back into modules/proxy/ (it's a c-t-r branch.) How you did it makes this a non-trivial exercise. Boo :( My plan is to start bringing it into httpd v2.1 from next week, assessing how hard the backports to httpd v2.0 would potentially be. Is the history kept in the tomcat connector tree enough, or is it critical to get the full history into httpd HEAD? If it weren't critical, the Apache Group would still be kicking around patch files and tarballs :) I'm looking at the mechanics of moving this already. 2.1-dev stays C-T-R just to avoid this sort of mess and encourage new contributions. If folks would focus on adding the new wiz-bang stuff to 2.1-dev, and not obsess over backports, 2.2 would already be out the door, IMHO :) Obviously, if there were no other way, it would be a no-brainer that some 2.0 feature (or separate downloadable patch) would be appropriate. It wouldn't be a stretch to have a little conditional #if APR_MAJOR 1 logic to offer backwards compatibility, then an end user could build their httpd with the 2.1-dev proxy tree instead of the 2.0 flavor. But with both _jk and _jk2, there are options - this is simply a monumental improvement over the old way. That's why versions exist in the first place :) Bill
Re: [proxy] New implementation ready for testing
William A. Rowe, Jr. wrote: Never cross my mind that we'll need all those try-error-fix commits back on the httpd cvs tree. We actually like those - the next individual to say wow - this fix is easy! can go back over history and say grumf - they tried that in the first place :) Question... ajp_header.lo ajp_link.lo ajp_msg.lo are all required by proxy_ajp Sure, they are all needed. any thoughts on how those will be kept in-sync or what folks should do to obtain? Have no idea. I was thinking that we leave the ajplib sources at j-t-c, so they can be copied over to /srclib or directly inside /modules/proxy/ajp when something major happens. We have discussed to add the compression and security support for ajp (AJP14 extensions), and also make the server side code (only the packet menagement API). All that was agreed on tomcat-dev prior we start coding. Since we are (Henri and myself, not sure for JeanFrederic) not httpd commiters, I'm not sure how the proxy_ajp will get maintained, but we can always send patches :) Regards, MT. smime.p7s Description: S/MIME Cryptographic Signature
Re: [proxy] New implementation ready for testing
Mladen Turk wrote: Since we are (Henri and myself, not sure for JeanFrederic) not httpd commiters, I'm not sure how the proxy_ajp will get maintained, but we can always send patches :) I'm quite happy to maintain the code, and can chase up any patches you send through in the mean time, if others don't beat me to it. Regards, Graham --
Re: [proxy] New implementation ready for testing
William A. Rowe, Jr. wrote: Since it will take some time to assess that the changes and new features are stable, v.s. dev quality, I believe it's sorta pointless to put extra energy into the 2.0 backport. We won't compromise mod_proxy again in 2.0 after its very slow crawl to some measure of stability. So count me a pretty strong -1 for backporting any major refactoring of proxy for 2.0. You know what pain it took for proxy to be accepted as useful (v.s. 1.3). This is a pretty significant leap, so it really doesn't make that much sense to compromise things. I see your point... In that case I'm now keen to see httpd v2.2 go out the door. :) One of the side effects of this work is that the connection pool and load balancing code is available to proxy_http as well as proxy_ajp, which means a performance boost to the HTTP proxy. The main reason I was keen to see an RPM spec file in the official release was to make it easy for people to use our most recent versions out in the real world, instead of vendor supplied more conservative releases (especially releases minus the experimental modules). It would be cool to see packaging for Debian, or Solaris, etc added as well. This would make it easy for people to deploy our latest releases without being forced to wait for the more conservative vendors to catch up, and in turn get httpd 2.2 onto more servers. Regards, Graham --
Re: [proxy] New implementation ready for testing
At 01:37 PM 8/11/2004, William A. Rowe, Jr. wrote: At 01:03 PM 8/11/2004, Graham Leggett wrote: My plan is to start bringing it into httpd v2.1 from next week, assessing how hard the backports to httpd v2.0 would potentially be. Is the history kept in the tomcat connector tree enough, or is it critical to get the full history into httpd HEAD? If it weren't critical, the Apache Group would still be kicking around patch files and tarballs :) sarcasm=off/ This has been committed with full history retained (dropping a few backed-out patches.) I'm looking at the mechanics of moving this already. This is done. Don't make me hurt you for causing more development on the jakarta-tomcat-connectors/ajp/proxy/ fork!!! Please blast that branch into the attic before someone sends my blood pressure through the roof (again :) Graham, please commit those patches from ajp developers as needed (for the time being.) Remember 2.0-HEAD is C-T-R. I've protected the -I ./ajp within the --enable-proxy-ajp feature, and fixed for broken vpath builds. What about adding a -with-ajp=/path/to/ajp feature, which would enable the proxy-ajp based on the --enable-proxy setting? As it stands with my commits, ajp is disabled unless explicitly enabled (due to the ajplib dependency.) I have no problems if we also add ajp* sources to either modules/proxy itself, or bury it in apr-util (should be brought up with the [EMAIL PROTECTED] list.) Bill
