tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johnny Kewl" <>
Subject Re: Tomcat failover
Date Tue, 12 Aug 2008 07:22:29 GMT

----- Original Message ----- 
From: "Ofer Kalisky" <>
To: "Tomcat Users List" <>
Sent: Tuesday, August 12, 2008 8:30 AM
Subject: Re: Tomcat failover

Is there a reason why no one is answering this?
  ----- Original Message ----- 
  From: Ofer Kalisky
  To: Tomcat Users List
  Sent: Monday, August 11, 2008 3:26 PM
  Subject: Tomcat failover


  I have a Tomcat that has a thread that reads entries from a DB and handles 
them. In each cycle, it reads all the entries (to a certain limit). I would 
like to set up a configuration that has a failover Tomcat, that when the 
first one crashes the second starts to read from the same DB (or a 
replicated, doesn't matter) and handle entries.
  I wouldn't want the second Tomcat to read from the DB, because it would 
harm the operation of the first when the first is up. I would like it to 
start working only when the first is down...

  How can I know in the second Tomcat that the first have crashed? can 
mod_jk help?


Yes MOD_JK is one way... maybe TC's clustering can also do it, but we have 
never gone that way...

Its transparent... ie you have n TC's behind JK... all do the same thing, if 
one crashes, the others just take over...
You dont really need replication, they all just talk to the same dB... dB's 
do multiple connections.

This scheme affects only those browsers that happen to be in that session...

TC also has a session replication thing... but we dont go that far.

In theory say you have 5 tomcats... they round robin... so 1/5 of the users 
are on one TC at anytime...
Say you have session that remembers the last page a user is in... if one 
machine fails, 1/5 of the users will lose their cookie and have to start at 
the first page again.

The next time they click on the link, the other TC's take over...

Regardless of the scheme... one can write good code and crap code... so TC 
cant fix stupidity... still need good designers that understand the system 
Replication has many other issues... rather just let each TC connect to the 
backend dB... and avoid things like storing images in the dB... then it will 
take an army of TC's to make a well designed dB tired...

On a dB... I feel its better to go for redundant disk arrays, before 
replication... but its just my pref.
Replication can get very complex... if the dB crashes, then there is a 
stoppage while disks are swapped over to a standby... that has never 
happened ;)

And now everyone else can tell you how they do it ;)

The most powerful application server on earth.
The only real POJO Application Server.
See it in Action :

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message