I wrote together a little idea (also emailed to geronimo-dev for
feedback) on how the next generation of session replication should be done.
Today's replication is an all-to-all replication, and within that realm,
its pretty poor. It creates way to much network traffic as each request
results in X number of network transmits (where X is the number of nodes
in the cluster/domain).
The suggested solution offers two advantages:
1. Each request with a dirty session should only result in 1 network
send (unless session create, session delete, or failover)
2. The session Manager (StandardManager,DeltaManager,etc) should not
have to know about replication, the DeltaManager today is too
complicated and too involved in the replication logic.
I propose a very simple, yet very efficient replication mechanism, that
is so straight forward that with a simple extension of the
StandardSession (if not even built in) you can have session replication.
It will even support future efforts for replication when we can have AOP
monitor the sessions itself for data that has changed without
setAttribute/removeAttribute, and the implementation wouldn't change much.
in my opinion, the Session API should not have to know about clustering
or session replication, nor should it need to worry about location.
the clustering API should take care of all of that.
the solution that we plan to implement for Tomcat is fairly straight
forward. Let me see if I can give an idea of how the API shouldn't need
to worry, its a little lengthy, but it shows that the Session and the
SessionManager need to know zero about clustering or session locations.
(this is only one solution, and other solutions should demonstrate the
same point, SessionAPI need to know nothing about clustering or session
locations)
1. Requirements to be implemented by the Session.java API
bool isDirty - (has the session changed in this request)
bool isDiffable - is the session able provide a diff
byte[] getSessionData() - returns the whole session
byte[] getSessionDiff() - optional, see isDiffable, resets the diff data
void setSessionDiff(byte[] diff) - optional, see isDiffable, apply
changes from another node
2. Requirements to be implemented by the SessionManager.java API
void setSessionMap(HashMap map) - makes the map implementation pluggable
3. And the key to this, is that we will have an implementation of a
LazyReplicatedHashMap
The key object in this map is the session Id.
The map entry object is an object that looks like this
ReplicatedEntry {
string id;//sessionid
bool isPrimary; //does this node hold the data
bool isBackup; //does this node hold backup data
Session session; //not null values for primary and backup nodes
Member primary; //information about the primary node
Member backup; //information about the backup node
}
The LazyReplicatedHashMap overrides get(key) and put(id,session)
So all the nodes will have the a sessionId,ReplicatedEntry combinations
in their session map. But only two nodes will have the actual data.
This solution is for sticky LB only, but when failover happens, the LB
can pick any node as each node knows where to get the data.
The newly selected node, will keep the backup node or select a new one,
and do a publish to the entire cluster of the locations.
As you can see, all-to-all communications only happens when a Session is
(created|destroyed|failover). Other than that it is primary-to-backup
communication only, and this can be in terms of diffs or entire sessions
using the isDirty or getDiff. This is triggered either by an interceptor
at the end of each request or by a batch process for less network jitter
but less accuracy (but adequate) for fail over.
What makes this possible will be that Tribes will have true state
replication and other true RPC calls into the cluster.
positive thoughts, criticism and bashing are all welcome :)
(remember that I work with the KISS principle)
http://people.apache.org/~fhanik/kiss.html
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
