Thanks for the info. We are using sticky sessions only with BackupManager. See We have the current setup.
1 Apache + sticky sessions with mod_ajp proxy balancer in httpd.conf + 10 tomcats. currently if one of our tomcat goes down the User sessions goes down, I need to stop this quickly somehow either by using deltamanager or Backupmanager. deltamanager all-to-all session replication is not feasible since our apps is heavy and memory chocks. We need a simple setup where all 9 tomcats should send session replication to 10th tomcat where app is also running. 10th tomcat has high hardware config in terms of memory+CPU. So please guide us on *server.xml change for 9 tomcats* and *server.xml for 10th Tomcat which is BackupManager*. We have sticky sessions config up and running. Regards, Dhaval, On Wed, Mar 21, 2012 at 2:58 PM, Mark Thomas <ma...@apache.org> wrote: > On 21/03/2012 09:15, Dhaval Jaiswal wrote: > > We have already server.xml(changed as per tomcat site instructions) > > in place, but it is not working properly. I will give you detail idea > > about our environment. > > > > We have 10 tomcats starting from 192.168.3.1 to 192.168.3.10. I > > wanted to make 192.168.3.10 as master/backup node, which has a > > session id information of rest 9 tomcats including 10 too. > > > > Kindly provide the clear example of server.xml of 192.168.3.10 > > (master/backup node) & rest of the 9 tomcats. > > The backup manager doesn't work the way you think it does. Consider a > four node cluster with nodes A, B, C & D. If node A has 30 primary > sessions (more on that on a sec) then 10 of them will be backed up on > node B, 10 on node C and 10 on node D. Sessions may be primary > (currently being used), backup (full copy of the primary) or proxy (no > data but knows which nodes are primary and backup). If a node isn't the > primary or a backup it will be a proxy. > > You have to use sticky sessions with the backup manager else the primary > node for the session keeps changing and that creates a lot of traffic. > > If the primary node fails, any other node can take over since they all > have either a backup or the proxy info. > > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
