tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dhaval Jaiswal <dhaval.jais...@via.com>
Subject Re: Need a sample server.xml file for the session replication using backup manager
Date Thu, 05 Apr 2012 13:57:19 GMT
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 <markt@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message