tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From nlif <>
Subject Re: Transfer all HttpSessions from one cluster node to another
Date Wed, 11 Feb 2009 11:44:39 GMT


I've got a basic implementation of this. Since I didn't want to change
Tomcat code, this is not the most elegant design. 

Here's what I've done:

I created a ManualFailoverManager class, which extends StandardManager. This
is a copy of the BackupManager, with these changes:

1) In the requestCompleted() method, I don't replicate the session.
2) In the start() method I replaced the LazyReplicatedMap with my own class:
3) I added a public, JMX exposed, method: failover() which simply calls
replicateAllSessions() in ManualReplicatedMap (see below).

I created a ManualReplicatedMap class, which extends LazyReplicatedMap, with
the following changes:

1) In publishEntryInfo() I simply return an empty Member array.
2) I added a method: replicateAllSessions() that does this:

Member[] allOthers = getMapMembersExcl(wrap(channel.getLocalMember(false)));

    for (Object key : keySet()) {
      MapEntry entry = (MapEntry) super.getInternal(key);
       * publish the data out to all nodes, as BACKUP.
      MapMessage msg = new MapMessage(getMapContextName(),
          MapMessage.MSG_BACKUP, false, (Serializable) key,
          (Serializable) entry.getValue(), null,

      try {
        getChannel().send(getMapMembers(), msg, getChannelSendOptions());
      catch (ChannelException e) {
        log.error("Unable to replicate backup key:" + key + ". Reason:"
            + e.getMessage(), e);

I'd be happy to get your feedback.

Moreover, there are a couple of points I am concerned about, which I'd be
happy to hear you thoughts on: 

I ended-up replicating to all other nodes in the cluster because I couldn't
think of a way to ensure that requests that were previously directed to Node
X will now be redirected to Node Y. Assuming I've got a load-balancer that
uses sticky-sessions, I still need a way to tell it to replace node X with
node Y. Since I am not sure that's possible, I had to replicate to all
nodes, so, whichever node gets the request, it can serve it. 

The question is - what is the status of all the session copies that end up

Another issue, is that of a possible race-condition during the replication
itself: I intend to replicate all sessions from Node X, remove it from the
load-balancer, and then shut it down. In that order. But what if while
replicating, a request comes in and changes the session being replicated?
Does tribes protect against that?

Alternatively, switching the order, and first removing Node X from the
load-balancer, and only then replicating, exposes me to the chance that a
request will come in to Node Y, which is the backup-to-be of the session,
while the session is not yet fully replicated. Again, does tribes handle

View this message in context:
Sent from the Tomcat - User mailing list archive at

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message