J2EE clustering, Part 1

Clustering technology is crucial to good Website design; do you know the basics?

1 2 3 Page 2
Page 2 of 3

Providing J2EE services on a single machine is trivial compared with providing the same services across a cluster. Due to the complications of clustering, every application server implements clustered components in unique ways. You should understand how vendors implement clustering and failover of entity beans, stateless session beans, stateful session beans, and JMS. Many vendors claim to support clustered components but their definitions of what that means usually involve components running in a cluster. For example, BEA WebLogic Server 5.1 supported clustered stateful session beans but if the server that the bean instance was on were to fail, all of the state would be lost. The client would then have to re-create and repopulate the stateful session bean, making it useless in a cluster. It wasn't until BEA WebLogic 6.0 that stateful session beans employed in-memory replication for failover and clustering.

All application servers support EJB clustering but vary greatly in their support of configurable automatic failover. Indeed, some application servers do not support automatic failover in any circumstance by EJB clients. For example, Sybase Enterprise Application Server supports stateful session bean failover if you load the bean's state from a database or serialization. As mentioned above, BEA WebLogic 6.0 supports stateful session bean failover through in-memory replication of stateful session bean state. Most application servers can have JMS running in a cluster but don't have load balancing or failover of individually named Topics and Queues. With that in mind, you'll probably need to purchase a clusterable implementation of JMS such as SonicMQ to get load balancing to Topics and Queues.

Another important consideration, to which we now turn our attention: HttpSession failover.

HttpSession failover

HttpSession failover allows a client to seamlessly get session information from another server in the cluster when the original server on which the client established a session fails. BEA WebLogic Server implements in-memory replication of session information, while HP Bluestone Total-e-Server utilizes a centralized session server with a backup for HA. SilverStream Application Server and Sybase Enterprise Application Server utilize a centralized database or filesystem that all application servers would read and write to.

The main drawback of database/filesystem session persistence centers around limited scalability when storing large or numerous objects in the HttpSession. Every time a user adds an object to the HttpSession, all of the objects in the session are serialized and written to a database or shared filesystem. Most application servers that utilize database session persistence advocate minimal use of the HttpSession to store objects, but this limits your Web application's architecture and design, especially if you are using the HttpSession to store cached user data.

Memory-based session persistence stores session information in-memory to a backup server. Two variations of this method exist. The first method writes HttpSession information to a centralized state server. All machines in the cluster write their HttpSession objects to this server. In the second method, each cluster node chooses an arbitrary backup node to store session information in-memory. Each time a user adds an object to the HttpSession, that object alone is serialized and added in-memory to a backup server.

Under these methods, if the number of servers in the cluster is low, the dedicated state server proves better than in-memory replication to an arbitrary backup server because it frees up CPU cycles for transaction processing and dynamic page generation.

On the other hand, when the number of machines in the cluster is large, the dedicated state server becomes the bottleneck and in-memory replication to an arbitrary backup server (versus a dedicated state server) will scale linearly as you add more servers. In addition, as you add more machines to the cluster you will need to constantly tune the state server by adding more RAM and CPUs. With in-memory replication to an arbitrary backup server, you just add more machines and the sessions evenly distribute themselves across all machines in the cluster. Memory-based persistence provides flexible Web application design, scalability, and high availability.

Now that we've tackled HttpSession failover, we will examine single points of failure.

Single points of failure

Cluster services without backup are known as single points of failure. They can cause the whole cluster or parts of your application to fail. For example, WebLogic JMS can have only a Topic running on a single machine within the cluster. If that machine happens to go down and your application relies on JMS Topics, your cluster will be down until another WebLogic instance is started with that JMS Topic. (Note that only durable messages will be delivered when the new instance is started.)

Ask yourself if your cluster has any single points of failure. If it does, you will need to gauge whether or not you can live with them based on your application requirements.

Next up, flexible scaling topologies.

Flexible scaling topologies

Clustering also requires a flexible layout of scaling topologies. Most application servers can take on the responsibilities of an HTTP server as well as those of an application server, as seen in Figure 1.

Figure 1. All-in-one topology Click on thumbnail to view full-size image. (6 KB)

The architecture illustrated in Figure 1 is good if most of your Website serves dynamic content. However, if your site serves mostly static content, then scaling the site would be an expensive proposition, as you would have to add more application servers to serve static HTML page requests. With that in mind, to scale the static portions of your Website, add Web servers; to scale the dynamic portions of your site, add application servers, as in Figure 2.

Figure 2. Partitioned topology Click on thumbnail to view full-size image. (7 KB)

The main drawback of the architecture shown in Figure 2: added latency for dynamic pages requests. However, it provides a flexible methodology for scaling static and dynamic portions of the site independently.

Finally, what application server discussion would be complete without a look at maintenance?


With a large number of machines in a cluster, maintenance revolves around keeping the cluster running and pushing out application changes. Application servers should provide agents to sense when critical services fail and then restart them or activate them on a backup server. Further, as changes and updates occur, an application server should provide an easy way to update and synchronize all servers in the cluster.

Sybase Enterprise Application Server and HP Bluestone Total-e-Server provide file and configuration synchronization services for clusters. Sybase Enterprise Application Server provides file and configuration synchronization services at the host, group, or cluster level. Bluestone offers file and configuration synchronization services only at the host level. If large applications as well as numerous changes need to be deployed, this process will take a long time. BEA WebLogic Server provides configuration synchronization only. Of the two, configuration synchronization with a storage area network works better because changes can be made to a single logical storage medium and all of the machines in the cluster will receive the application file changes. Each machine then only has to receive configuration changes from a centralized configuration server. SilverStream Application server loads application files and configuration from a database using dynamic class loaders. The dynamic class loaders facilitate application changes in a running application server.

That concludes our look at the important features to consider in application servers. Next let's look at how our four popular application servers handle themselves in relation to our criteria.

Application server comparisons

Now that we have talked about clusters in general, let's focus our attention upon individual application servers and apply what we learned to the real world. Below, you'll find comparisons of:

  • HP Bluestone Total-e-Server 7.2.1
  • Sybase Enterprise Application Server 3.6
  • SilverStream Application Server 3.7
  • BEA WebLogic Server 6.0

Each application server section provides a picture of an HA architecture followed by a summary of important features as presented in this article.

HP Bluestone Total-e-Server 7.2.1

Figure 3. HP Bluestone 7.2.1 topology. Click on thumbnail to view full-size image. (8 KB)

General cluster summary:

Bluestone implements independent JNDI tree clustering. An LBB, which runs as a plug-in within a Web server, provides load balancing and failover of HTTP requests. LBBs know which applications are running on which UBS (universal business server) instance and can direct traffic appropriately. Failover of stateful and stateless session and entity beans is supported in between method calls through EJB Proxy Service and Proxy LBB. The main disadvantages of EJB Proxy Service are that it adds extra latency to each EJB request and it runs on the same machine as the UBS instances. The EJB Proxy Service and UBS stubs allow failover in case of UBS instance failure but do not allow failover in case of hardware failure. Hardware failover is supported through client-side configuration of apserver.txt or Proxy LBB configuration of apserver.txt. The client-side apserver.txt lists all of the components in the cluster. When additional components are added to the cluster, all clients need to be updated through the BAM (Bluestone Application Manager) or manually on a host-by-host basis. Configuring apserver.txt on the Proxy LBB insulates clients from changes in the cluster but again adds additional latency to each EJB call. HP Bluestone is the only application server to provide clustered and load-balanced JMS. Cluster convergence time:

Least, when compared with centralized and shared global JNDI tree clusters.

HttpSession failover:

In-memory centralized state server and backup state server or database.

Single points of failure:


Flexible cluster topology:

All clustering topologies are supported.


Bluestone excels at maintenance. Bluestone provides a dynamic application launcher (DAL) that the LBB calls when an application or machine is down. The DAL can restart applications on the primary or backup machine. In addition, Bluestone provides a configuration and deployment tool called Bluestone Application Manager (BAM), which can deploy application packages and their associated configuration files. The single downside of this tool is that you can configure only one host at a time -- problematic for large clusters.

Sybase Enterprise Application Server 3.6

Figure 4. Sybase Enterprise Application Server 3.6 topology. Click on thumbnail to view full-size image. (5 KB)

General cluster summary:

Enterprise Application Server implements centralized JNDI tree clustering, and a hardware load balancer provides load balancing and failover of HTTP requests. The two name servers per cluster can handle HTTP requests, but for performance considerations they typically should be dedicated exclusively to handling JNDI requests.

Enterprise Application Server 3.6 does not have Web server plug-ins; they will, however, be available with the EBF (Error and Bug Fixes) for 3.6.1 in February. The application supports stateful and stateless session and entity bean failover in between method calls. Keep in mind that Enterprise Application Server does not provide any monitoring agents or dynamic application launchers, requiring you to buy a third-party solution like Veritas Cluster Server for the single points of failure or automatic server restarts. Enterprise Application Server does not support JMS.

Cluster convergence time:

Convergence time depends on the number of name servers and member servers in the cluster. Of the three cluster implementations, centralized JNDI tree clusters produce the worst convergence times. Although convergence time is important, member machines can start receiving requests after binding objects into a name server that is utilized by an EJB client (this is not recommended, however).

HttpSession failover:

HttpSession failover occurs through a centralized database. There's no option for in-memory replication.

Single points of failure:

No single points of failure exist if running multiple name servers.

Flexible cluster topology:

A flexible cluster topology is limited due to the lack of Web server plug-ins.


Sybase provides the best option for application deployment through a file and configuration synchronization. It can synchronize clusters at the component, package, servlet, application, or Web application level. You can also choose to synchronize a cluster, group of machines, or individual host -- an awesome feature but it can take a while if there are many machines in the cluster and many files to add or update. A weakness is the lack of dynamic application launching services, which means you must purchase a third-party solution such as Veritas Cluster Server.

SilverStream Application Server 3.7

Figure 5. SilverStream Application Server dispatcher topology. Click on thumbnail to view full-size image. (6 KB)
Figure 6. SilverStream Application Server Web server integration module topology. Click on thumb- nail to view full-size image. (6 KB)

General cluster summary:

When setting up a SilverStream cluster, choose from two configurations: dispatcher-based or Web server integration-module (WSI)-based. In a dispatcher-based cluster, a user connects to the dispatcher or hardware-based dispatcher -- Alteon 180e, for example. Then the dispatcher sends an HTTP redirect to pin the client to a machine in the cluster. From that point on, the client is physically bound to a single server. In the dispatcher configuration there is no difference between a single machine and cluster because, as far as the client is concerned, the cluster becomes a single machine. The major disadvantage: you can't scale the static portions of the site independently of the dynamic portions.

1 2 3 Page 2
Page 2 of 3