Cluster-enabled, Server-initiated Rendering

Cluster-enabled, Server-initiated Rendering

Before exploring server-initiated rendering in a cluster, you should be familiar with the concepts of basic server-initiated rendering and the Rendering API. See Server-initiated Rendering API in the ICEfaces Developer's Guide.

Server-initiated rendering provides a mechanism for updating clients that are using an ICEfaces application based on server-side triggers and is a standard feature of the ICEfaces CE. The implementation provided in ICEfaces CE is not cluster-enabled, and as such, will not provide expected behavior in a clustered deployment. Specifically, server-initiated render calls only affect the clients on the node where the render call is triggered, which may not be sufficient for certain types of applications, where common data is shared among clients on different nodes of the cluster.

For example, consider a chat application deployed in a load-balanced cluster, backed by a shared database. As each user logs in, the load balancer directs the request to one of the nodes in the cluster based on some algorithm (round-robin, weight-based, etc.) and the application updates the database with the new user information. The application interface may have a list of active users displayed that needs to be updated as each new person logs in. With a single node, you simply use the Server-initiated Rendering API to create a rendering group with all active clients and request a server-initiated render whenever a new user is added. In a cluster, this approach only renders those clients that happen to be on the same node as the new user. The clients on other nodes only see the new information when they next get rendered and pull the latest information out of the database. Without a server-initiated render, when this happens is unpredictable.

To solve this, ICEfaces EE includes a server-initiated render broadcast feature, which tells all the nodes in the cluster that a render has been requested for a named group renderer.

With ICEfaces CE, you use an instance of the RenderManager and, through its API, you can request server-initiated renders of individuals or create group renderers for requesting renders on multiple users. There are different group render implementations to facilitate on-demand rendering, interval rendering, and delayed rendering. To support server-initiated renders across nodes in a cluster, ICEfaces EE provides a BroadcastRenderManager. It supports the same API as the RenderManager with the addition of a single new method:
relayRenderRequest( String renderGroupName )
 
Many types of server-initiated renders do not have to be broadcast across nodes. For example, if your application had a ticking clock that requests a render every 60 seconds, each instance of the application on each node in the cluster would have its own group renderer for the clock. At each 60 second interval, the clock would update everyone on that node and it would be unnecessary to broadcast the render request across the nodes. In these situations, the BroadcastRenderManager can be used in the same way as the basic RenderManager, managing server-initiated rendering on the local node only.

Referring back to our chat example, if a user on node A sends a chat message to chat room 1, the users on nodes B and C who are also in chat room 1 should be re-rendered so that they can see the latest message. In this situation, you'll want to use the BroadcastRenderManager like so:
relayRenderRequest( "chatRoom1" )
 
The BroadcastRenderManager ensures that the message gets sent to all the other nodes in the cluster and that requestRender() gets called on the group renderer named "chatRoom1".

The BroadcastRenderManager is a wrapper around the basic RenderManager. It provides the additional capability of relaying render requests across all the nodes in a cluster via JMS. The instance of BroadcastRenderManager on each node acts as both a publisher and subscriber to a specifically configured JMS topic and uses this topic to both broadcast (publish) and receive (subscribe) to render request messages. As render request messages arrive, the BroadcastRenderManager locates the appropriately named group renderer and calls its requestRender() method.