Hey Jules,
thanks for commenting, I will pop in on codehaus devlists.
The lazy replicated map supports more than one backup node, with a very
small tweak in just one method, you can change it to be N number of
backup nodes. N being configurable, just a matter of getting the conf
param down to the impl level.
Apache Tribes, as I like to nickname the Tomcat group communication
protocol, has an implementation at
http://svn.apache.org/viewcvs.cgi/tomcat/container/tc5.5.x/modules/groupcom/
including the LazyReplicatedMap and a MapDemo (you're gonna be awed by
my Swing skills).
I am also in the place of implementing a regular ReplicatedMap, to use
for context attribute replication, a feature sought after.
I will subscribe to the WADI list and we can continue over there re:
session management.
Filip
Jules Gosnell wrote:
Filip Hanik - Dev Lists wrote:
gentlemen, not a committer here, but wanted to share some thoughts.
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.
We are 100% in agreement here, Filip.
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
So, delta-ed sessions, at whole session or attribute granularity ? and
when will you be sending the deltas - immediately, end of
request[-group], pluggable strategies ?
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)
interesting...
So all the nodes will have the a sessionId,ReplicatedEntry
combinations in their session map. But only two
two is a fixed number or deploy-time parameter ?
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.
I see - that answers my question about when replication occurs :-)
As you can see, access time is not relevant here, nor does the
Session API even know about clustering.
yes !
In tomcat we have separated out group communication into a separate
module, we are implementing the LazyReplicatedHashMap right now just
for this purpose.
positive thoughts, criticism and bashing are all welcome :)
This approach has much more in common with WADI's - in fact there is
lot of synergy here. I think the WADI and TC clustering teams could
learn a lot from each other. I would be very interested in sitting
down with you Filip and having a long chat about session management.
Do you have a Tomcat clustering-specific list that I could jump onto ?
You might be interested in popping in on [EMAIL PROTECTED] and
learning a little more about WADI ?
regards,
Jules
Filip
