Location

"Location, Location, Location!"

The Location of resources is all-important in a Cluster. The sum of all e.g. Sessions, may be too large for copies of all of them to be held on every node (not to mention the issues associated with trying to keep all these copies up to date).

A WADI Partition is responsible for maintaining a Map of session-id:session-location for a distinct subset of the cluster's sessions.

Each node can deduce the Partition to which a session belongs by applying a simple algorithm to its ID.

Each node knows which node is responsible for each of the fixed number of Partitions. (This information is disseminated around the cluster every time ownership of a Partition changes).

Thus, it follows that any node can find the whereabouts of any session, by using its ID to decide who knows where it is and then asking them.

The flipside of this is that each time a session is created, migrated, or destroyed, its corresponding Partition must be notified of this change. (In future, WADI will try to ensure that sessions are generally created and destroyed on the node that holds their Partition, so minimising network traffic - but in exceptional cases a session may have to be moved elsewhere)..

We can watch this occurring in WADI.

Start your red and green nodes.

Create a Session on the red node, using e.g. the following link: http://localhost:8080/wadi/session.jsp.

Note that red will say something like:

2005/12/07 17:54:29:292 GMT [DEBUG] ClusteredManager - -creation: A931056AACF210B8058025F67E1204CB

and whichever node is the Partition Master for the newly created session will report its notification e.g. thus (in this case Partition #3, currently serviced by green, is reporting that it has just been notified of the [re]location of a session on red):

2005/12/07 17:54:29:271 GMT [DEBUG] LocalPartition#3@green - -insert: A931056AACF210B8058025F67E1204CB {red}

Your browser should be returning a page looking something like this:

The background of the page is red because it was served from the red node. There is a table containing one cell, because we have only touched the page once. This cell is red, because it was allocated on the red node.

Refresh the page a couple of times. Notice that, since everything is now local, we do not see any more location-oriented messages. You should end up with something like this :

Since we have touched the page three times now on the red node, we have three red cells.

Now we can try asking for the same session on the green node. Try hitting e.g. http://localhost:8081/wadi/session.jsp.

red should say something like this:

2005/12/07 17:59:52:207 GMT [DEBUG] Utils - -motion: A9518C9C6BAB34CDBEE765DF60AE6A76 : memory -> emigration:green (74 millis)

green should say something like this:

2005/12/07 17:59:52:195 GMT [DEBUG] Utils - -motion: A9518C9C6BAB34CDBEE765DF60AE6A76 : immigration:red -> memory (40 millis)

and the Partition Master should report the change of session location:

LocalPartition#46@red - -move: A9518C9C6BAB34CDBEE765DF60AE6A76 {red->green}

Finally your browser should now have a page like this:

The table may be thought of as a history of the session's location in the cluster. You should be able to see from the colour of the page and the new cell, that the session has now moved to the green node.

Just to be sure, refresh the page a couple of times.

You get the idea...

NOTE - we should demonstrate the destruction of the session and its removal from the Partition as well...

The transparent relocation of sessions beneath incoming requests is an important part of WADI's ability to ensure that request and session meet somewhere in the cluster in order to correctly render the response.