Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "RAP/RWT Cluster"

< RAP
m (Test Infrastructure)
(Transparent Session Failover)
Line 14: Line 14:
  
 
In §7.7.2 (Distributed Environments), the servlet specification requests for distributable aplications that all session data must implement the <code>Serializable</code> interface. This results in two main abstacles to overcome with the current implementation:
 
In §7.7.2 (Distributed Environments), the servlet specification requests for distributable aplications that all session data must implement the <code>Serializable</code> interface. This results in two main abstacles to overcome with the current implementation:
* All RWT objects that live in the session scope must be serializable. This will mainly affect Display, Widget and derived classes and Resource and derived classes.
+
* All RWT objects that live in the session scope (i.e. are directly or indirectly stored in a session attribute) must be serializable. This will mainly affect Display, Widget and derived classes and Resource and derived classes.
 
* The RWTLifeCycle which creates a ''UI Thread'' that lives until the session is terminated. The UI thread is necessary to enable blocking dialogs and so ensures compatibility with SWT. The downside of the UI thread of course is that sessions cannot be migeated as - naturally - a thread cannot be serialized.
 
* The RWTLifeCycle which creates a ''UI Thread'' that lives until the session is terminated. The UI thread is necessary to enable blocking dialogs and so ensures compatibility with SWT. The downside of the UI thread of course is that sessions cannot be migeated as - naturally - a thread cannot be serialized.
  

Revision as of 07:33, 13 June 2011

| RAP wiki home | RAP project home |

Warning2.png
Support for Transparent Session Failover in RWT is work in progress and details outlined below may change without prior notice


Load balancing

Load balancing to distribute workload across multiple nodes in a cluster works with RAP out of the box since version 1.0.

One thing to mind though when setting up a load balancer for RAP applications is that it must be configured to use stcky sessoins (aka session affinity). This entails that once a session is started, the same server serves all requests for that session.

For information on how to set up load balancing, refer to the servlet container documentation. E.g. Tomcat


Transparent Session Failover

We are currently working to make transparent session failover possible for RAP applications so that they can run in a high-availability cluster. This means that two or more servlet engines form a cluster, where a session, and its contents, can be moved from any node of the cluster to a different node.

In §7.7.2 (Distributed Environments), the servlet specification requests for distributable aplications that all session data must implement the Serializable interface. This results in two main abstacles to overcome with the current implementation:

  • All RWT objects that live in the session scope (i.e. are directly or indirectly stored in a session attribute) must be serializable. This will mainly affect Display, Widget and derived classes and Resource and derived classes.
  • The RWTLifeCycle which creates a UI Thread that lives until the session is terminated. The UI thread is necessary to enable blocking dialogs and so ensures compatibility with SWT. The downside of the UI thread of course is that sessions cannot be migeated as - naturally - a thread cannot be serialized.

Serializable RWT sessions can also be used to swap inactive sessions onto disk and thereby releasing the memory consumed by them. This feature is e.g. supported by Tomcat

State of Development

Bug bug 341761 is used as a meta-bug to capture the problem and track the solution. For details, please see the bugs that this bug depends on.

Alternative life cycle

An alternative life cycle implementation is availiable that does not use an extra thread. As a consequence thereof blocking dialogs aren't possible with this life cycle.

Serializable session data

The core classes with session scope are now serializable and a simple Shell with a Button should work.

Test Infrastructure

To be able to run tests from JUnit, we wrote test helper classes with which we can start an arbitrary number of embedded serlvet engines and have them form a cluster. Currently the tests can be run with Jetty 7.4 and Tomcat 7.

The tests reside in org.eclipse.rap.rwt.cluster.test and the fixture can be found in org.eclipse.rap.rwt.cluster.testfixture. Tests for the fixture in turn are in org.eclipse.rap.rwt.cluster.testfixture.test.

Configuration

In order to run an RWT application in a cluster configuration, an additional servlet filter must be registered. The web.xml should look like the one below:

  <?xml version="1.0" encoding="UTF-8"?>
  <web-app version="2.4" 
    <context-param>
      <param-name>org.eclipse.rwt.entryPoints</param-name>
      <param-value> the class name of your entry point goes here </param-value>
    </context-param>
    <listener>
      <listener-class>org.eclipse.rwt.internal.engine.RWTServletContextListener</listener-class>
    </listener>
    <servlet>
      <servlet-name>rwtServlet</servlet-name>
      <servlet-class>org.eclipse.rwt.internal.engine.RWTDelegate</servlet-class>
    </servlet>
    <filter-mapping>
      <filter-name>org.eclipse.rwt.internal.engine.RWTClusterSupport</filter-name>
      <servlet-name>rwtServlet</servlet-name>
    </filter-mapping>
    <servlet-mapping>
      <servlet-name>RWTServlet</servlet-name>
      <url-pattern>/</url-pattern>
    </servlet-mapping>
  </web-app>

In addition the threadless life cycle must be selected. To do so, set the lifecycle system property to org.eclipse.rwt.internal.lifecycle.SimpleLifeCycle. The means to configure RWT to use this life cycle will chnage with the ongoing work on bug 347883 As this life cycle does not support Display#sleep() and Display#wake(), the readAndDispatch loop must be removed from the entry point. Make your entry point look like the one below.

public class SimpleEntryPoint implements IEntryPoint {
  public int createUI() {
    Display display = Display.getDefault();
    Shell shell = new Shell( display );
    shell.setBounds( 10, 10, 850, 600 );
    shell.setText( "Hello World" );
    // create more widgets...
    shell.open();
    return 0;
  }
}

Development Snapshots

Development takes place in HEAD, if you are interested you may want to directly check out the source from the source code repository. Nightly builds are also available and can be downloaded from the build server.

If you whish to run the cluster tests, you will have to add Jetty 7.4 and the H2 database (version 1.1) to your target platform. The Eclipse Orbit project offers a bundled version of H2. Please note that the download does not contain these tests.

Schedule

We plan to ship the first version with milestone 1 of RAP 1.5 which will be available end of August 2011. The exact date depends on the Juno/Simultaneous Release Plan.

Back to the top