RAP 2.0 Countdown (4/5)

While we are waiting for the RAP 2.0 release to be published on Monday, I’m introducing you to the most important changes in this major release. For today, I’ve picked a slightly trickier part of RAP: the server push. RAP has built-in server push support, and a brand new push API in 2.0. Let me use the opportunity to shed some light on this topic.

[ Need support for a mission-critical system? Get Production Support with up to 12x5 coverage by Eclipse experts. | More on RAP from our blog: RAP technology overview ]

What is Server Push and Why Should I Care?

An HTTP server cannot simply “push” information onto the client. It has to wait for the client to ask for changes. Server push techniques allow clients to be notified immediately in the event of a server-side change. In RAP, server push comes into play whenever you access the UI from a thread that is not the UI thread, that is, outside of the normal event handler code.

Normal Operation (The Blue Part)

Let’s start with the simple case. I’d like to ask you to focus only on the blue part of the diagram below and try to cut out everything else for now.

Whenever an event occurs (e.g. a button press), the client sends a POST request to the server with a JSON message that contains the event. All event handler code is executed in the UIThread on the server. Any changes to the UI made in this thread are immediately sent to the client.

Background Processing (The Red Part)

Now let’s add the dark red line to the picture (green is still invisible). Another thread is forked from the UI thread to execute some background task. We use to call those non-UI threads background threads. In SWT, the UI may only be accessed from the UI thread. When you want to update the UI from a background thread, you have to wrap the respective code in a runnable and hand it over to Display.asyncExec() or syncExec(). The runnable will be put into a queue to be executed in the UI thread.

The runnables in this queue can be processed in the UI thread only when the client sends another POST request. The updates will not appear on the user’s screen until there is some user interaction.

Server Push (Green)

Now for the green part. When server push is enabled, the client will send a GET request everytime a POST returns. This GET request is blocked on the server, so the client keeps waiting for a response. When Display.asyncExec() is called and a runnable put into the queue, the server releases the blocked request and sends an empty response. This notifies the client to send another POST request to fetch the updates from the server.

As you can see, this process results in a continuous serpentine line that keeps the client up to date.

The New Server Push API

In RAP 1.x, this feature was called UICallBack. Since “server push” has become an established term, we decided to use this for the new API. However, there’s no ServerPush class, but only a ServerPushSession. Instead of activating the server push directly, you create and start a push session. There can be multiple overlapping push sessions throughout your code, and as long as at least one of them is active, the framework will keep the green part enabled.

To request server push, create a new ServerPushSession and call start on it. It’s crucial to do that in the UIThread before you fork a background thread. When your code doesn’t require the server push anymore, call stop() on the push session. That’s all. In contrast to the old API, you can stop the session from any thread you like.

final ServerPushSession pushSession = new ServerPushSession();
Runnable runnable = new Runnable() {
  public void run() {

    // do some background work ...

    // update the UI
    display.asyncExec( new Runnable() {
      public void run() {
        if( !label.isDisposed() ) {
          label.setText( "updated" );
        }
      }
    } );

    // close push session when no longer needed
    pushSession.stop();
  };
};

// start push session before starting the thread
pushSession.start();
Thread thread = new Thread( runnable );
thread.setDaemon( true );
thread.start();

The server push in RAP has gone through many iterations. It has been completely reworked in RAP 1.5 and again revised in 2.0. For example, one improvement in 2.0 is that the client is now immediately notified in case of a session timeout when server push is enabled. So I’m pleased to say that the server push in RAP 2.0 is now very robust and mature.

RAP 2.0 will be published on Monday around noon CET.

[ This post belongs to the RAP 2.0 Countdown series. Continue with part 5 or go back to part 3. ]