Henri Gomez wrote:
And what about using AJP/1.3 instead of HTTP for connection to tomcat ?)
In all my deployments of tomcat I have never seen the point of a custom protocol that did exactly what HTTP does, so all my tomcat deployments are all HTTP, with a simple mod_proxy frontend.
Even the "get Apache to server static content" feature wasn't enough of a drawcard, as proper HTTP cache handling and a suitable cache solved this problem. It was far more important for me to arrange the web application as a self contained unit - I would rather be more tidy with an install at the expense of a slightly higher load, than sacrifice a clean install to save some cycles.
- If you add load-balancing/fault-tolerance and AJP 1.3 support in mod_proxy you'll have about 99% of the current functionalities of jk 1.2.x.
We discussed also the need for some dynamic mapping and topology discovery/update (between Apache and Tomcats Clusters).
Proxy has a placeholder in it that says "put the code to make decision about load balancing etc here" - all that is needed is a hook and a module "proxy_loadbalancing.c" to make it happen.
And in fine, we like to have some JMX like functionnalities in Apache 2, in our case CMX for C Management Extension, a way to update Apache 2.x configuration while the server is running...
This is possibly a whole separate project in itself.
I have been meaning to work on a get-apache-config-out-of-ldap extension for a while, what it really should be is "get apache config out of wherever", but this should be an Apache wide thing, not limited to a single module or technology.
I think using mod_proxy is acceptable for our most important needs, as the Tomcat HTTP/1.1 connnector has acceptable performance.
We would need:
- JSESSIONID stickiness
- persistent connections support
- (and of course) load balancing (with a static worker list) with failover
- bonus points for auto retry (if the request allows it) to another node when recieving a 503 status
SSL client-cert support (which I have no idea how to implement with mod_proxy, or maybe I missed something) and more generally, support for doing auth on the native webserver doesn't seem to be there, which is a problem.
For ease of use, we need this "Tomcat" policy (actually, it's not Tomcat specific, obviously) to be included in the Apache source distribution, and ready to enable.
I would like a more custom solution better, but if that's the only acceptable solution for you (and you accept the module into the Apache ;) ), then I'm ok with it.
In this case, we would need another, more complex connector for the advanced use cases, but we would have addressed the needs of the majority of users.
Rémy
