In terms of integrating mod_jk/mod_webapp, I think this might be worthwhile
-- specifically, mod_jk was built to handle a variety of protocols (ajp12,
ajp13, etc.). So writing a protocol handler for the mod_webapp protocol
would give a lot of benefits -- load-balancing, support for a variety of web
servers, debugged C code. Pier had mentioned a while ago that the mod_jk
code was completely incomprehensible. Gal Shachor basically wrote his own
object system in C, which is very, very confusing at first. I've added a
lot of comments in the 3.3 branch, particularly to common/jk_service.h, with
the explicit goal of making it easier for people to write new protocol
handlers and/or new web server plugins.
One thing I can imagine being a problem right off the bat would be that the
abstractions which allow mod_jk to deal with a variety of web servers may
not support the fine-grained control over configuration which mod_webapp
supports.
Splitting off a connectors sub-project: I don't think I support this -- it
was discussed on the list a few months ago, and my objections from then
still hold.
Sharing session-information around: feels way too complex -- I think there
are better ways to get persistent sessions. Overloading the
(already-complicated) web server/servlet container communication stream
seems like asking for trouble we don't need.
-Dan
GOMEZ Henri wrote:
>
> Fine to see mod_webapp back to life :)
>
> 1) You added many features interesting in building (autoconf, apr)
> which we could study to adapt to mod_jk (at least autoconf).
>
> 2) I plan to update the mod_webapp RPM and hope the code will compile
> under GCC (it wasn't the case with tc 4.0b2/b3)
>
> 3) You still didn't tell us what you think into merging mod_webapp
> and mod_jk.
>
> Why not use mod_webapp/mod_jk to start the
> web-connector sub-project allowing us to remove many question
> related to connectors from Tomcat user/dev lists ?
>
> The same web-connector project could be used against
> Tomcat 3.2/3.3/4.0 but not be restricted to Tomcat.
> Any project understanding the concept of HTTP request/reply
> could use it.
>
> Much more what about using the connector to have the Apache
> store sessions (serialized) data from Tomcat.
>
> Here is the idea :
>
> - One Apache may be connected to multiple Tomcat (TomcatA/TomcatB).
>
> - Each Tomcat have sessions related data which may be good to
> see available to other Tomcats in case of failure :
>
> ie:
>
> TomcatA create a session and data in that session.
>
> When replying to Apache (via mod_jk or mod_webapp) it also
> send the session datas (serialized) when they are created
> (or updated).
>
> Apache store that informations for possible future use (db1/gdb)
>
> TomcatA fail (stopped, restarted, jvm dumped...) and Apache
> (via at least mod_jk) decide to route the request to TomcatB.
> TomcatB miss the session datas allready generated by TomcatA but
>
> Apache could route the request ALONG WITH THE previously saved
> session
> informations. TomcatB could then recreate the session, set the
> session data and then serve the request in the same condition that
> TomcatA.
>
> You get a real fault-tolerant system (no need to resign in some
> case).
>
> What do you think about that proposal (Costin, Craig, Dan, Jon, Pier...)
>
> -
> Henri Gomez ___[_]____
> EMAIL : [EMAIL PROTECTED] (. .)
> PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
--
Dan Milstein // [EMAIL PROTECTED]
