Mladen Turk wrote:
Graham Leggett wrote:
I don't think that it is necessary for a mod_ajp to be
included inside
the mod_proxy, although they are sharing some common concepts.
I think it's very necessary - sharing those common concepts ultimately makes for doing things in a consistent way. It makes a big difference to the usability of httpd.
I'm sure that the 'normalization' would lead to nowhere.
Right now proxy is able to talk HTTP and FTP (and CONNECT, but it's a special case). It makes the most sense for AJP to be added to these three protocols, as there is already an established way to do this.
Consistency is very important.
Having load
balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different.
Different to what? Load balancing is load balancing, whether the backend protocol is HTTP, AJP or FTP.
HTTP is a statles protocol, and our concept is to have a constant connection pool to the well known application server. So, unlike HTTP protocol we are embedding the remote application server, and it just happens that we are doing it using the same TCP/IP protocol for that.
I see no point on making significant effort in a feature that can only be used for one protocol, that's a huge waste of an opportunity to solve the load balancing problems of backends other than tomcat.
Quite contraty, this is the main reason. We already have jk2 that can be used even for proxying HTTP requests. Are you wiling to write the http protocol for mod_jk2?
The purpose of mod_ajp is to communicate with the (one or
more of them
in a
cluster) application servers using ajp13+ protocol; simple as that.
Proxy allows you to communicate with (one or more in a cluster) applications servers using HTTP or FTP. The only difference is the protocol.
Again, application server != http server.
The development of proxy_ajp could see the development of modules like proxy_loadbalance or proxy_sticky, which have general application outside of the AJP protocol.
Agreed, pehaps some day they will convolve to the single module, but right now I don't see the point for it, especialy when the mod_proxy is well established module.
Just rewriting mod_ajp for v2.0 isn't anything different to what exists now, so I don't see the point.
Well, that's how you see it. IMO trying again to squize the apache2->Tomcat module inside some already present solution would again lead to nowhere, and finally rise the questions like we are rising today.
Not sure since mod_proxy will associate to a ajp://VIRTUALNAME, and in such case it's up to proxy_ajp to decide to :
- keep the socket open - handle a pool of socket - fall back to another AJP instance in the cluster.
So I think it could be done
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
