High availability clustering for RAP/RWT in Eclipse Juno

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.

  • Stefan
    Posted at 1:00 pm, June 16, 2011

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

  • Posted at 1:45 pm, June 16, 2011


  • Mark
    Posted at 4:18 am, June 17, 2011

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