really awesome work Gianny, I know you've worked very hard on it.
Filip
David Jencks wrote:
Wow this is great!!
Are there instructions somewhere on how to set up a demo system?
Having an integration test would be even better :-)
thanks
david jencks
On Jan 6, 2007, at 7:30 PM, Gianny Damour wrote:
Hi,
I think that support for clustered Web-applications with Jetty is now
working.
Here is a description of how this works; note that most of the
described behavior is WADI specific.
Group Communication
Group communications are performed by Tribes, which is the Tomcat 6
group communication engine. I know very little of Tribes; however, I
am pretty sure that Filip Hanik can give us an in-depth description,
if requested. At a very high level, Tribes provides membership
discovery and failure detection. It also provides basic message
exchange communication primitives, that WADI builds upon to provide
additional message exchange operations (e.g. request-reply).
Logical group communication engines are layered on top of the above
(physical) group communication engine. A logical group communication
engine, a ServiceSpace in the WADI's terminology, provides the same
features than a physical group communication engine and allows the
definition of sub-groups. This means that at the physical level, you
could have three nodes interconnected and at the logical level only
two of them could appear as existing.
Clustered Web-Application Discovery
A clustered Web-application is placed into a logical group
communication engine, which is uniquely identified by a URI. This URI
is the Artifact id of the Web-application configuration. When this
Web-application starts, the logical group communication engine starts
and joins the logical sub-group identified by its unique id.
Conversely, when the application stops, the logical group
communication engine leaves the logical sub-group.
Partitioned State
WADI implements a partitioned session state topology. In a cluster
all the session states are distributed across the cluster nodes and
only one node holds the state of a given session. This design choice
was made to improve scalability with respect to the size of data to
be managed by a single node. Session locations, information required
when a node requests a session that it does not hold, are also
managed by a single node. When a node fails, the session states and
session locations managed by this node are lost and WADI is able to
recreate them. Session states are lazily recreated from replicas.
Session locations are recreated by querying the cluster and asking
each member what are the sessions that they are currently holding.
Session Creation
When an inbound request wants to create a new HttpSession, a WADI
session is created. This session is hosted by the node receiving the
inbound request. An HttpSession using under the cover the WADI
session is then created and returned. Under the cover, WADI ensures
that the session has a unique identifier cluster-wide.
Session Migration
When an inbound request wants to access an HttpSession and this
session is not hosted by the node, The node hosting the requested
session migrates it to the node receiving the request. Under the
cover, WADI ensures correct handling of concurrent session migration
requests via a locking approach and maintains its internal book
keeping of session locations following migration events.
Session Replication
When a request complete, the WADI session used under the cover of the
HttpSession is notified. The WADI session is then replicated
synchronously to one or multiple nodes. The selection of the back-up
nodes for each session is customizable via a plugin strategy.
When a node fails, replicas are re-organized based on the new list of
existing members.
Fail-Over
When an inbound request wants to access an HttpSession, which was
hosted by a node which has died, the cluster is queried for a replica
of the requested session and an HttpSession is recreated if possible.
Session Evacuation
When a Web-application stops, all the session that it holds are
evacuated to the other nodes hosting the same clustered Web-application.
It will take me 1 to 2 weeks to test specific error scenarios and
ensure correctness; meanwhile, if anyone wants to know more of some
specific areas, then please feel free to ask.
Thanks,
Gianny
--No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.6/617 - Release Date:
1/5/2007 11:11 AM
