tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Filip Hanik" <m...@filip.net>
Subject RE: Connector persistance across multiple apache frontends
Date Wed, 25 Jun 2003 01:29:37 GMT
>- 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:funkman@joedog.org]
> 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: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message