High availability clustering for RAP/RWT in Eclipse Juno

Computer cluster, taken from http://thefullwiki.org/Parallel_programming

While most of us are busy with that latest bits of the Indigo release, some have the joy to work on one of the next new features in RAP: support for high availablity clusters.

Let me briefly mark out what we mean by clustering support and what we don’t. Load balancing clusters are used if you whish to provide your applications to a large number of users. If your application provides critical servies you may also want to make it fail safe by running it in a high availablity cluster.

A high availability cluster operates by having redundant nodes. So that if one node crashes, the service as a whole is unafected as other nodes take over the work. Whereas load balancing RAP applications is possible since ever, failover clusters put further requirements on the framework.

To be able to migrate sessions between nodes in a cluster, all session data has to be serializable. Also, the current implementation preserves the server-side execution flow within a UIThread in order to single-source RCP applications. These two form the main work areas.

  • All session data must be prepared for distributing sessions among cluster nodes for failsafe operation.
  • A new life cycle for processing requests without a UIThread was implemented and RAP can be configured to run with either of them.

The new life cycle also makes it easier to access security or transaction contexts and is conform to the JEE Specification. If you don’t use blocking dialogs or workbench features and want to be able to eventually run your application in a cluster – then this is for you.

For more details, see the RAP Wiki.

5 Responses to “High availability clustering for RAP/RWT in Eclipse Juno”

  1. Stefan says:

    Sounds cool. How do you handle listeners attached to SWT widgets? Do they need to be serializable, too?

  2. @Stefan
    Sure, listeners need to implement Serializable. Currently widget listeners (i.e. SelectionListener) do not implement Serializable. This means that application code has to take care that each listener that is attached to objects in session scope does implement Serializable.
    Things are in an early stage, we may find a more convenient solution in the future.

  3. Mark says:

    Thanks for the update. Does operating without the UI thread mean that UICallback#activate and UICallback#deactivate are not supported?

  4. @Mark
    UICallback#activate and #deactivate are not affected by the new (non UI thread) life cycle. You can use the new life cycle and the UI callback without any problems.
    UICallback#activate() is usually used to propagate changes from background threads to the UI. I am not sure yet if it is feasible to use background threads (even with certain constraints) in a high availability environment.
    If high availability isn’t needed you may still use the threadless life cycle, e.g. to ease integration with JEE.

5 responses so far

Written by . Published in Categories: EclipseSource News, Planet Eclipse

Looking for a job?

Karlsruhe / Remote
Karlsruhe / Victoria / Remote
Karlsruhe / Victoria / Remote