You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by nlif <na...@plimus.com> on 2009/02/11 12:44:39 UTC

Re: Transfer all HttpSessions from one cluster node to another

Filip,

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:
ManualReplicatedMap.
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);
      entry.setBackupNodes(allOthers);
      /*
       * publish the data out to all nodes, as BACKUP.
       */
      MapMessage msg = new MapMessage(getMapContextName(),
          MapMessage.MSG_BACKUP, false, (Serializable) key,
          (Serializable) entry.getValue(), null,
channel.getLocalMember(false),
          allOthers);

      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
unused?

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
that?

Naaman
-- 
View this message in context: http://www.nabble.com/Transfer-all-HttpSessions-from-one-cluster-node-to-another-tp21649886p21953141.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


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