>> 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...
How could you be silent on that since you're the only developper
on mod_webapp ?
I didn't see why a flamewar must start here. What we're discussing
here is technic not politic, and it's an open and honest thread.
mod_jk is the de-facto standard to link a web server (not only
Apache) to tomcat. mod_webapp is really new and having it
incompatible with mod_jk will raise more questions and requests
than necessary.
>> 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 proposal is simple. Just remove all connector stuff, both native
and java code from tomcat 3.3/4.0 tree and move it to another sub-project.
As I said it will remove connectors questions from Tomcat list.
Merging mod_jk and mod_webapp will help people switching from
Tomcat 3.2.x to Tomcat 4.0 without changing anything from there
webserver side.
Many sites will strongly require to have a AJP12/AJP13 connectors
in Tomcat 4.0 since they may have mixed Tomcats systems 3.x and
4.0 and we just can't demand them to just do the 'big bang' and
replace their running mod_jserv/mod_jk by mod_webapp.
the ajp12/ajp13 integration in Tomcat 4.0 is a pragmatic and
realist choice.
What about VOTE like :
[ ] I want to have a ajp12/ajp13 in Tomcat 4.0 ?
[ ] I don't want to have a ajp12/ajp13 in Tomcat 4.0 ?
>> 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...
What's 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)
Did there is a project somewhere to store the session outside the tomcat ?
A persistant session storage hosted in a web server may be bad but I'm
ready to try other solutions ....
Henri (Going Bed)
