GOMEZ Henri at [EMAIL PROTECTED] wrote:
> Fine to see mod_webapp back to life :)
Well, I don't really know how happy I am...
> 1) You added many features interesting in building (autoconf, apr)
> which we could study to adapt to mod_jk (at least autoconf).
That's what was expected, I believe....
> 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)
Wait until a release is tagged...
> 3) You still didn't tell us what you think into merging mod_webapp
> and mod_jk.
And I'll continue to be silent on that... As I don't really want to start
another flamewar... I've been thru enough already on that, and all I can say
is that I'll let the people on this list (but me) decide...
> 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 ?
Make a proposal...
> 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.
Probably what you want to see is something more like mod_backend...
> 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).
I don't see this as a viable solution... Storing session data within the web
server itself is tricky, and definitely not what I would like to see, but I
live up the decision to the list...
How do you approach the case where multiple web servers are a front end to
multiple servlet containers? I still doubt that storing sessions in the
server does the trick...
> What do you think about that proposal (Costin, Craig, Dan, Jon, Pier...)
The only solution I see is to have sessions shared on the back of the
servlet container, and do the web server do its job (without loading up with
too much crap)
Pier (off to bed...)
