WADI - Frequently Asked Questions

General

  1. How is WADI pronounced? [20/04/04]
  2. What does WADI stand for? [20/04/04]
  3. What does WADI do? [13/05/07]
  4. What are WADI's goals? [08/06/04]
  5. What resolutions to these goals does WADI propose? [22/11/05]
  6. With which J2EE containers is it integrated? [22/11/05]
  7. Why would I even want to store important information in the Web tier? [19/04/04]
  8. Why should I need it? [19/04/04]
  9. How does it differentiate itself from the competition? [22/11/05]
  10. So tell me about WADI and mod_jk [22/11/05]
  11. What is WADI's current status? [13/05/07]
  12. How does WADI relate to Apache Geronimo? [22/11/05]
  13. This is interesting stuff - how do I get involved? [22/11/05]
Technical
  1. How is WADI put together? [19/04/04]
  2. How do you deal with concurrency in a webapp's HttpSessions? [19/04/04]
  3. Tell me what you mean by State, e.g. HttpSession, and Invocation, e.g. HttpRequest, migration [13/05/07]

General

How is WADI pronounced? [20/04/04]
WADI is pronounced: 'woddy'.
[top]
What does WADI stand for? [20/04/04]
W[eb] A[pplication] D[istribution] I[nfrastructure].
[top]
What does WADI do? [13/05/07]
WADI is a clustering framework that manages and ensures the scalable and transparent high availability of state and services.

Such state is stored in a Session. This is the per-client server-side repository of state and the only resource to be distributed in a clustered application.

WADI's goal is to identify and explain the shortcomings present in current offerings and to provide an implementation which draws upon this crystallisation of the current state of play to provide a highly flexible toolkit capable of delivering a number of different solutions in a complex problem space.

WADI is able to achieve this, because the project is focussed, not on the delivery of a complete, working web-container, but simply upon the problem of distributed state management.

Ultimately, WADI will live or die upon its ability to deliver a production-ready implementation of this in a format that is sufficiently performant, flexible, and functional.
[top]
What are WADI's goals? [08/06/04]
In the Web tier, we can crystallise WADI's goals into two stages:
  • To be able to walk into your web farm and 'ctl-c' any webcontainer node without losing any HttpSessions (i.e. customers).
  • To be able to walk into the same web farm and 'kill -9' any webcontainer node without losing any HttpSessions (i.e. customers).

The first of these two cases is important because it allows easy maintenance of existing h/w or s/w. This may seem a trivial requirement, but many existing solutions are time-consuming and/or error-prone (involving draining sessions off target nodes over long periods etc.), to the point that many sites simply accept that maintenance will impact quality of service.

The second of these two cases deals with a more exceptional case - the catastrophic failure of a webcontainer node. As online competition for business increases, systems are being required to provide higher and higher levels of availibility. This can be critical in particular areas. The ability to preserve web-tier state beyond the failure of its node is correspondingly an increasing requirement.
[top]
What resolutions to these goals does WADI propose? [22/11/05]
WADI addresses its problem space through dividing and conquering. The goals above have been broken down into the following feature set.
  • A reliable solution to application and container space HttpSession concurrency issues - so that the container may safely serialise a session if/when the need arises.
  • The ability to migrate sessions to/from a pluggable shared long-term storage mechanism allows WADI to preserve JVM resources by evicting infrequently used sessions during a node's lifetime and to ensure their availibility to its peers both during its lifetime and after shutdown.
  • Further pluggable strategies allow the user to control e.g. compression algorithms used in such migration. These could be extended to perform other types of transformation - e.g. encryption, for sites where security is a priority.
  • WADI is able to relocate sessions by migration directly between peer nodes in the cluster. If a request arrives at a node that does not have the corresponding session, it can locate it and arrange its immigration underneath the incoming request.
  • WADI is also able to relocate requests between peers. It uses redirection (load-balancer integration permitting) or proxying. If a request arrives at a node that does not have the corresponding session, it can locate it and send the request on to the correct node..
  • Bulletproof HttpSessions - through state replication.
  • All of the above in a manner completely compatible with the current J2EE Servlet Specification (2.4), thus preserving the users investment in the J2EE platform and avoiding vendor lockin.
HttpSessions have taken a back seat, in terms of reliability and effort put into their implementation, to EJBs for some time. With the proliferation of web farms and increasing reliability and performance requirements in the web tier, WADI will address these issues.
[top]
With which J2EE containers is it integrated? [22/11/05]
WADI currently plugs into in the form of a clustered implementationg of an HttpSession Manager. Any other web container that is flexible enough to allow the substitution of its HttpSession Manager with another 3rd party implementation should present a fairly straightforward integration target for WADI.

[top]
Why would I even want to store important information in the Web tier? [19/04/04]
Strictly speaking, data associated with presentation lives in the web tier whilst data associated with the business should be stored in the EJB tier.

State management in the EJB tier is more tightly specified, simpler and generally better implemented than the equivalent functionality in the web-tier, so the tendancy has been to push all important data in this direction, when high availibility and fail-over are a major concern.

Unfortunately, even designs such as the above cannot get away from the fact that the web-client requires a single handle on the conversational state held in some J2EE tier and that the only such handle provided by the J2EE specifications is that which binds a url parameter/session cookie to a web session. So whilst you can store all data in the EJB tier, unless you want to start learning proprietary tricks to associate an EJB handle with a web client, you have no option but to put your EJB into the relevant web session and pray that it survives whatever gets thrown at it.

This is obviously an unsatisfactory state of affairs, and WADI's aim is to restore confidence in the reliability of web sessions in general and to clearly demonstrate, that with a little thought, in a number of cases, a distributed web session may be implemented more efficiently and reliably than the corresponding stateful EJB session.
[top]
Why should I need it? [19/04/04]
If you have a requirement to store presentation state in your J2EE web tier and this state is of value and you are not keen on shoehorning it into the business tier in order to achieve its persistance and distribution, then you should be looking at WADI.
[top]
How does it differentiate itself from the competition? [22/11/05]
The competition is HttpSession implementations in the open source world. At the time of writing, and to the best of my knowledge, these begin to address the same issues as WADI, in terms of e.g. paging HttpSessions to/from disc, or state replication, but have unclear semantics under concurrent load, or are lacking important features. I haven't found a single implementation which addresses all the issues which WADI chooses to in one package - otherwise I would have contributed to that project.

Here is a brief summary of the current state of play:

Implementation Session Persistance Shared Store Session Eviction Session Replication Replication Whole/Delta Replication Partitioned Replication Technology Author
Jetty5,6/TC5.0,5.5: WADI Y Y Y NYI - Y NYI - both NYI - auto - pluggable ActiveCluster/Pluggable Jules Gosnell The WADI Team
Jetty4/5: Jules' DSM Y Y N Y both manual JGroups/Pluggable Jules Gosnell
TC4/JBoss: Thomas' DSM N N N Y whole manual JBossHA/JGroups Thomas Peuss
TC5: PersistentManager Y ? Y N N N N/A Kief Morris
TC5: DeltaManager N N N delta N? ? JGroups? Filip Hanik, Craig McClanahan, Jean-Francois Arcand
TC5: SimpleTcpReplicationManager N N N Y delta N? JGroups Filip Hanik, Bela Ban
TC5: - New JCluster-based ? ? ? ? ? NYI - auto - clock JCluster/JGroups Rob Block

Please notify us of mistakes or other features/implementations that you would like to see in this table.
[top]
So tell me about WADI and mod_jk [22/11/05]
Mod_jk poses particular problems for session maintenance beyond the lifetime of a single vm. Mod_jk implements session affinity via a contract with the webcontainer. Each node has a unique id. This id is appended to any session created on this node i.e. if a session '1234' is created on node 'red', the cookie returned to the browser will have a value of '1234.red'. Mod_jk's workers.properties is used to map the 'red' to a particular host:port combination each time it is seen. This is a very efficient and effective way of achieving affinity, until 'red' disappears. Then the browser is left holding a cookie with no corresponding node. Rather than implementing a contract involving some sort of predictability, e.g. failing over to the next node in the list. Mod_jk will simply treat the session as if it had no affinity and select a 'random' live node and drop the request on it. Subsequent requests will be routed to different nodes, whilst the session cookie still ends in '.red'.

How does WADI maintain a session's availability in these circumstances ? If 'red' is shutdown cleanly it will migrate its sessions to its surviving peers. The next request will cause the node upon which it lands to acquire the relevant session from a peer, if it does not already own it, and then process the request in the normal manner. This node will then rewrite the routing info at the end of the session id with its own unique id, sticking all subsequent requests to itself. Thus affinity immediately 'fails-over' onto another node, maintaining session availibility at minimum price paid only in the exceptional case.
[top]
What is WADI's current status? [13/05/07]

WADI is assumed to be production ready: implemented features have been successfully tested under multiple failure scenarios.

[top]
How does WADI relate to Apache Geronimo? [22/11/05]
WADI started life as a design for a Jetty/Geronimo component. We soon realized that, because of WADI's abstraction of all significant functionality into pluggable strategies with well-defined APIs, there would ultimately be nothing tieing it exclusively to Jetty or Geronimo. At this point it became WADI - a standalone project, now able to be used by a wider audience.

[top]
This is interesting stuff - how do I get involved? [22/11/05]
Work you way through the Getting Started documentation and the Maven2 and Eclipse Developers sections on the WIKI. Get onto the mailing lists, report problems here or on Codehaus Jira.Bug fixes are always welcome :-). These are the ways to have a direct impact on the quality and direction of the project

[top]

Technical

How is WADI put together? [19/04/04]
WADI installs as an HttpSession Manager for a particular Context/WebApp. This Manager then installs (programmatically) a Filter at the front of the webapp's Filter stack.

The Manager may be considered to be the webapp's HttpSession factory. It is in control of HttpSession creation and destruction and provides its own HttpSession implementation. Both Tomcat and Jetty (fortunately) have well defined internal Manager and HttpSession APIs. org.codehaus.wadi.shared provides core classes which implement standard and WADI functionality as well as interfaces defining pluggable strategies and policies. org.codehaus.wadi.tomcat and org.codehaus.wadi.jetty extend these classes with the necessary glue to fit them into the targer webcontainer. Finally, org.codehaus.wadi.plugins provides concrete implementations of these pluggable APIs, e.g. HttpSession and HttpRequest relocation mechanisms.

WADI does not set out to tell you how to distribute your webapp. We believe that there are many different ways that you might wish to do this. WADI simply provides a framework and (eventually) every conceivable ability that you might require. Useful default behaviour is supplied, but it is expected that this will be customised with the use of the supplied plugins.
[top]
How do you deal with concurrency in a webapp's HttpSessions? [19/04/04]
The servlet spec specifically mandates that implementations should allow multiple concurrent request threads to pass through an HttpSession. It omits describing any synchronisation protocol around the HttpSession that the container and application might use in order to coordinate their activities. This has presented a problem for a number of Manager implementations that I have looked at. Many chose simply to ignore the problem.

This problem becomes far more pressing as the number of activities that the Manager may wish to perform on an active HttpSession increases in frequency or complexity. WADI, for instance, needs to be able to guarantee that no application threads are altering an HttpSession's content whilst the Manager is trying to serialise the HttpSession as part of a relocation (migration) to long term store or another node.

Synchronising around the HttpSession would not actually solve our problem. If we wish to relocate an HttpSession to another node, we must prevent, once we have made this decision any further requests for this session on this node from entering application code here during the relocation.

WADI intercepts and looks at each incoming request. If it references a local HttpSession it tries to acquire a non-exclusive lock in that HttpSession (non-exclusive so that many concurrent request threads may run). When the Manager wishes to e.g. relocate the HttpSession it will try to acquire an exclusive lock in the HttpSession. In this way application and container-space threads are properly coordinated.
[top]
Tell me what you mean by State, e.g. HttpSession, and Invocation, e.g. HttpRequest, migration [13/05/07]
Introducing state into a cluster thoroughly complicates matters. It becomes important that client request and server-side state meet each other somewhere in the cluster for correct processing. Location becomes all important. WADI has the ability to migrate both State, e.g. HttpSessions, by migrating it from node to node (or to long term store) and to migrate Invocation, e.g. HttpRequests, by redirection and proxying.
[top]