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]
