>- Use the clustring facilities. But in tomcat4 they are more or less >experimental. In tomcat5 - they will be MUCH better.
they are actually almost the same. The tomcat 4 clustering is a back port of the Tomcat 5 cluster code and can be found at http://cvs.apache.org/~fhanik/ Filip > -----Original Message----- > From: Tim Funk [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 24, 2003 6:24 PM > To: Tomcat Users List > Subject: Re: Connector persistance across multiple apache frontends > Yes. In each tomcat, you will need in server.xml > <Engine jvmRoute="someUniqueTomcatId" ...> > > Then each uniqueTomcatId will need to be in workers.properties > (or whatever > config file you make apache use). Then all the 'uniqueTomcatId' > workers sit > behind a loadbalancer worker also defined in worker.properties. > > The drawback is if a tomcat goes down, then you lose the session > in a user > tries to go to that instance. Luckily you can persist all > sessions to a file > and hope for a quick restart to minimize the amout of damage. Otherwise, > there are 2 workarounds: > - Persist session data in a database > - Use the clustring facilities. But in tomcat4 they are more or less > experimental. In tomcat5 - they will be MUCH better. > > The faq has a lot of links to other sites and to the docs: > http://jakarta.apache.org/tomcat/faq/connectors.html > > -Tim > > Dan Hart wrote: > > Please forgive my ignorance in this matter and the inherant rudeness in > > asking a question moments after subscribing to this list. > > > > The short question: Is it possible to maintain persistant connections > > across a line of front-end apache 1.3 linux boxen? > > The goal is high availability. If possible, please > > point me in the right direction of finding > > documentation on this ability. > > > > Diagram: > > ======== > > > > Hardware LB Level: BigIP (Redundant, of course) > > | > > +----+----+----+----+----+--... > > | | | | | | ... > > Webserver Level: webA webB webC webD webE webF ... > > (Apache + mod_jk) | | | | | | ... > > +----+----+----+----+----+----+--... > > | | | | | | | ... > > Tomcat Level: tc1 tc2 tc3 tc4 tc5 tc6 tc7 ... > > (On Solaris 8) | | | | | | | ... > > +----+----+----+----+----+----+--... > > Database Level: | > > Database (Redundant, of course) > > > > > > Details: > > ======== > > > > I understand on a basic level how the mod_jk connector works, > mainly from > > documentation found in the worker's HOWTO. To quote: > > > > * sticky_session specifies whether requests with SESSION ID's > > should be routed back to the same Tomcat worker. > > If sticky_session is an int and is not 0 it is set > > to JK_TRUE and sessions are sticky, otherwise > > sticky_session is set to false. Set sticky_session > > to JK_FALSE when Tomcat is using a Session Manager > > which can persist session data across multiple > > instances of Tomcat. By default sticky_session > > is set to JK_TRUE. > > > > This appears to refer to a single apache instance. It also seems to be > > enabled by default, which would explain the difficulty in finding > > documentation on it ;) From past experience with mod_jserv, I know I > > could do this setup using ApJServRoute directives (assuming > these were the > > same across all systems, of course). > > > > So is this possible with mod_jk? My assumption is that "Yes, of course > > this is possible you twat and is enabled by default even!" however such > > answers tend to go poorly at higher levels of management. So a piece of > > official documentation showing this would be highly appreciated. > > > > Thanks! > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
