httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Gomez <hgo...@apache.org>
Subject Re: Invitation to HTTPD commiters in tomcat-dev
Date Wed, 21 Jul 2004 09:48:57 GMT
Mladen Turk wrote:
>  
> 
> 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.




Mime
View raw message