Re: [proxy] New implementation ready for testing
William A. Rowe, Jr. wrote: 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 :) No need for java include since ajp implementation is the one using network support, no jni involved :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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:
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
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/balancer-howto.html#Using%20Apache%202%20with%20mod_proxy%20and%20mod_rewrite
Performance is very bad (much worse than mod_jk, according to testing),
failover is questionable, and load balancing policies are not available.
So this is definitely a great hack, and it's likely very useful for some
people but it's not generic enough, and definitely isn't a marketable
solution.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
Concerning session stickyness: is the following scenario possible with your mod_proxy, at least in the future? We support a critical high load application which is running in a two cell environment. We replicate via TC cluster locally inside each cell (2 TCs) but not over the boundaries of the cells (cluster would be to big and for a cell outage it would be acceptable to loose sessions). So a cell is equal to a replication domain resp. to a TC cluster. Let's say TCs with jvmRoute A1, A2, B1, B2, where A and B are the cells. Also we use session stickyness on multiple Apache/mod_jk to keep hopping of requests from primary to secondary TCs low. Any apache needs to send requests sticky to the correct TC instance. Both TC clusters provide the same webapps. Now, if TC A1 is going down for maintenance (or breaks), and apache receives a request with jvmRoute A1, it should send the request to another member of the same cluster, in this case A2 and not to B1 or B2. Could this be done with mod_proxy? I did some project patches for mod_jk to make this happen (adding an attribute domain to the balanced_workers and enhancing get_most_suitable_worker in the lb worker. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proxy] New implementation ready for testing
Rainer Jung wrote: Concerning session stickyness: is the following scenario possible with your mod_proxy, at least in the future?e We support a critical high load application which is running in a two cell environment. We replicate via TC cluster locally inside each cell (2 TCs) but not over the boundaries of the cells (cluster would be to big and for a cell outage it would be acceptable to loose sessions). So a cell is equal to a replication domain resp. to a TC cluster. Let's say TCs with jvmRoute A1, A2, B1, B2, where A and B are the cells. Also we use session stickyness on multiple Apache/mod_jk to keep hopping of requests from primary to secondary TCs low. Any apache needs to send requests sticky to the correct TC instance. Both TC clusters provide the same webapps. Now, if TC A1 is going down for maintenance (or breaks), and apache receives a request with jvmRoute A1, it should send the request to another member of the same cluster, in this case A2 and not to B1 or B2. Could this be done with mod_proxy? I did some project patches for mod_jk to make this happen (adding an attribute domain to the balanced_workers and enhancing get_most_suitable_worker in the lb worker. Think that the routeRedirect should be sufficient enough. If the particular node is marked *disabled* then the requests will be redirected to that node. So you will have to manually edit your 'domains', meaning: Node A1 - routeRedirect A2, etc... This scenario is already supported inside proxy_balancer and jk2. MT. smime.p7s Description: S/MIME Cryptographic Signature
[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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
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: 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. So compared to AJP, this gives what ? Q: is there session stickiness in HTTP ? Congratulations for improving on mod_jk performance :) 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. Does it do session stickiness right now ? 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. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
Remy Maucherat wrote: Q: is there session stickiness in HTTP ? As I understood from the commits, stickiness is part of balancer, and balancer is protocol independant, which would make the answer yes. Am I understanding correctly? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: [proxy] New implementation ready for testing
Remy Maucherat wrote: So compared to AJP, this gives what ? Nothing regarding performance :) Or you can use the https to connect to the tomcat on the internet. Q: is there session stickiness in HTTP ? Yes. Congratulations for improving on mod_jk performance :) proxy_balancer: Does it do session stickiness right now ? Yes, and redirect_route too. In addition it has options missing from jk. The sticky session param/cookie is configurable. You have a force-sticky option (if there is no backend session replication). MT. smime.p7s Description: S/MIME Cryptographic Signature
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: Re: [proxy] New implementation ready for testing
Mr./mrs. Moderator I am a Turkish. I don't want those e - mails. Do you Yahoo!? Yahoo! Mail is new and improved - Check it out!---BeginMessage--- 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 ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
