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
