Tom Drake wrote: > > Mathias; > > Thanks for your very informative reply. From your reply, it seems > that mod_jk comes close to doing what I want, and should actually > provide the fail-over I'm looking for, however not in the most > optimal way. > > What would be involved in adding (optionally configured) logic to > mod_jk that would prefer another running instance over a downed > instance, and then remember this as the 'jvmroute' for the given > JSESSIONID?
Humm the design Gal Shachor did for mod_jk is pretty slick, there is no need to maintain any session table in Apache memory as the jvmroute is part of the session id. Therefore I do not see any way coherent with that design to re-route a given session id (containing a jvmroute not to be used) to a new Tomcat in a sticky way. My best shot would be, the first time a request is received on a Tomcat which did not issue it, to reissue Set-Cookie and Set-Cookie2 headers to force a new session id to be used. Therefore the mapping would be explicit in the new session id. The new session id would have to be used also in URL rewritings. This solution would provide the re-mapping you requested and the new Tomcat would become the new session parent. There are though several drawbacks to issueing a new session id. First the marketing guys won't be happy :-) Their client tracking would probably suffer from this change of session id, even if the end user doesn't notice anything. Second, depending if you use load balancing equipment before the Apache servers, and what kind of stickyness you use those equipments with, you could end up with non optimal routings of requests, but that's only minor since it will only apply to sessions that were on the downed worker initially. > Can you provide any insights into mod_webapp? Nope, I only dug into mod_jk for now. Mathias. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
