Graham Leggett wrote:
Thing is it's easier for end users to not have to mess around with third party builds if it can possibly be avoided, and it's the needs of the end users who are the most important, not the developers.
It was the main reason why we tried to go beyond the concepts of jk/jk2 and
co. Also, nowadays almost every server implementation requires some sort of
dynamic context delivery.
Ajp concept has a nice feature not being dependant on any external toolkits
like for example mod_perl and php are, so it's a good candidate for
inclusion inside the core distribution.
The fact that the current module has to be built separately is a huge issue for the users of the module, making such a module a built in addition to proxy will make people's lives easier.
Henri tried to see if there is a common interest to possibly make a mod_ajp part of the core distribution. Think that discussion is leading to use the mod_proxy like a container for ajp protocol, that could be fine, but something like mod_proxy concept we already have in the jk2, called modular protocol. The main reason why we are trying to make a successor for jk/jk2 is simplicity and static set of requirements. Trying again to use the something would lead to the same problems thought.
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. Having load balancer on top of mod_proxy would be a nice feature, but the main purpose for them is different. 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 module has a conceptually different approach, and it is meant to be used for different purposes.
I think it would be better that we develop the module inside j-t-c tree, and kindly ask the guys to see if there is a possibility to include it in the core distribution, when we reach some level of stability.
Good resume Mladen.
Many nice things was discussed on this thread :
- adding load-balancing/fault-tolerant support for mod_proxy.
A nice features to provide to mod_proxy users, and as such not dedicated to tomcat users.
So it could (should ?) be an extension developped by mod_proxy and HTTPD team. And if they could make the lb/ft algorythm easy configurable (ie handling JSESSION_ID), it will be perfectly feeted for users who want to use the HTTP/1.1 connector of their servlet engines (tomcat of course, but it could be others like jetty).
- adding ajp_proxy support to mod_proxy.
With that mod_proxy could relay request to ajp:// pseudo URL. JK/JK2 developpers should learn how to make a mod_proxy sub module, and play for example with brigade :)
In such case, there is no direct lb/ft support, so it will depend on the previously mentionned support in mod_proxy itself.
- creating a mod_ajp which will mimics mod_proxy features but with jk/jk2 features in mind.
- our actual lb/ft support (which should be more simple or better
documented). - at a later time, dynamic topology (tomcat clusters state changes,
application state in each tomcat, update of tomcat load level...)I'm more than pleased to read that httpd members see mod_ajp/ajp_proxy
as something to be included in HTTPD tree, now or may be after an incubation period in the jakarta-tomcat-connector sub project.
Of course it will make the couple Apache/Tomcat ready to use and as such easier for some of us to 'sell' to their clients and IT managers.
So what should we do now ?
- An initial step seems to extract all ajp functionnalities from jk/jk2, into an ajp library (or some c/h files). Basic AJP functions should use APR for all OS/NET/MEMORY operations and there is some code ready for this in jk2.
- int ajp_open_connection(ajp_connection_t **, char *, apr_port_t)
- int ajp_close_connection(ajp_connection_t *)
- int ajp_send_request_headers(ajp_connection_t *, apr_table_entry_t *);
- int ajp_send_request_datas(ajp_connection_t *, apr_pool_t *) - int ajp_receive_reply(ajp_connection_t *, apr_pool_t *)
All of this should be using only APR objects like apr_socket_t, apr_sockaddr_t, apr_table_entry_t (headers), apr_pool_t...
Next advanced AJP functions will forward a complete Apache 2 request to a tomcat. Many objects part of the Ap2 request are allready available in the Basic AJP functions, ie for headers the apr_table_entry_t...
We could then work on a mod_ajp prototype, using only env var for example, to redirect a request to the correct named ajp instance (don't speak about worker).
With such simple prototype we could see which hooks should be implemented, probably only ap_hook_handler/ap_hook_post_config.
Actually jk 1.2.x may implements too many hooks, I didn't see any Apache 2 modules with all of these :
ap_hook_handler(jk_handler,NULL,NULL,APR_HOOK_MIDDLE);
ap_hook_post_config(jk_post_config,NULL,NULL,APR_HOOK_MIDDLE);
ap_hook_child_init(jk_child_init,NULL,NULL,APR_HOOK_MIDDLE);
ap_hook_translate_name(jk_translate,NULL,NULL,APR_HOOK_MIDDLE);
ap_hook_map_to_storage(jk_map_to_storage,NULL,NULL,APR_HOOK_MIDDLE);
Regards.
