Thank you for being a valued client of CM First Group. If you have any technical issues or concerns, please open a ticket on, email CM First technical support at or call us on our 24/7 customer hotline at +1 (512) 623-7586.


CM WebClient on Multi-Server, Load-Balanced Environment

Background information

A high-availability system makes use of multiple hardware and software components such as servers, databases, web servers, load balancers, and others, in a variety of configurations, to ensure an application is always available and that sessions can be maintained.

Due to the complexity and large numbers of high-availability implementation options, this concept document will focus only on the following architecture: a CM WebClient application implemented on a Tomcat App server running a Liferay portal. CM WebClient will access a two server, load-balanced cluster using Liferay.

Session persistence is critical for high-availability configurations; it requires the implementation of a Session Manager to manage the lifecycle and session state for a web application. The implementation of such Manager varies depending on the software components used, i.e., each Web Portal such as Websphere, Liferay, etc., may have their own session management approach to implement session management. Session Persistence is out of the scope of this document.

The Cost of Session Replication

You can ensure session persistence by replicating it across multiple servers in the clusters. Although there can be benefits to session replication, there are also costs to consider:

Performance. Session Replication requires the copying of sessions' data across all servers in the cluster. The larger the number of servers in the cluster, the larger the overheads involved and the more adversely performance is impacted.

  • Memory. As more concurrent users connect to the application, more data needs to be stored in memory for each session. This memory allocation can lead to systems performance issues or potentially even failure.
  • Coding and Program Modifications. Applications that support Session Replication require serialization and this commonly requires coding or program modifications to support it. Serializing session data also involves overhead and potentially increased waits in order to replicate the session state. Therefore, developers need to keep the session size reasonably small.

Session Replication requires serialization of the web applications it contains. CA Plex applications are not serializable as the CA Plex Runtime doesn't allow serialization and replication from one server to another, due to the complexities of multi-tier applications that extend beyond the web server environment into the underlying database servers or IBM I application tiers. As CA Plex applications are not serializable, session replication is not possible.

For additional details on CA Plex check the CA Communities forum at

At the time of this writing no other restriction has been found in CM WebClient for its operation within a highly available environment or with its implementation as an application running within a Portal application.

The above constraint doesn’t imply that a CM WebClient application cannot operate in a multi-server environment with high availability. The serialization restriction only impacts one aspect of ensuring availability. This document will demonstrate the setup that will allow a CM WebClient application to operate across multiple servers. It will show that if a server goes down, the user can quickly become operational again without session replication.

Document Goals

  • Set up a simple load-balancer configuration with two Tomcat instances and Liferay portal
  • Liferay set up to operate with two servers
  • Set up to have the CM WebClient app run within Liferay
  • Simulate a cluster failure by disabling one server connection and having Liferay operate with the other server
  • Document what happens with CM WebClient application. During this process, the user should refresh the application as the original session would be lost. The app should start with the other server
  • Demonstrate that the Liferay errors related to serialization are just a warning and not errors that indicate the CM WebClient application is not operating properly

This proof of concept document describes the aspect of load balancing with two servers. Load balancing is only one component of a high-availability cluster. In the particular case of a highly scalable Liferay configuration, additional components such as the ones below that MIN, James (2015) describes as part of a highly-scalable configuration are not considered in this test and documentation:

  • Centralized Database
  • Ehcache
  • Lucene
  • Document Library and Image Gallery


This document represents a Proof of Concept and doesn't describe all the details required to implement a high availability, multi-server, clustered application with CM WebClient nor is it an implicit guarantee that all aspects of a CM WebClient application integration with Liferay are ensured.

back to top

Process to Set Up CM WebClient to Work with Two Load-Balanced Servers

Process Components

A high-availability implementation aims at providing a fully reliable system where connections are maintained and new sessions can always be created. Such implementations can be quite complex such as shown in Figure 1:

(LIFERAY, 2015).

This test will consider the minimum high-availability configuration to exemplify the access of a CM WebClient application running on the Liferay portal to access two servers.

Tomcat, the Web Server considered for this conceptual test, doesn’t provide a failover capability to redirect incoming traffic to the next available server in a cluster. Therefore, a load balancer setup is required (LIFERAY, 2015).

This simplified test will demonstrate the configuration shown in Figure 2.

FIGURE 2 – Basic, High-Availability Test – CM WebClient Application Hosted in LIferay on a Two Web-Server, Load-Balanced Cluster

The procedure involves the following stages and steps:

back to top

Components Installation and Configuration

Download and Install Liferay

This test makes use of Liferay which can be downloaded from

Details on the particular version to install may vary. Check on Liferay’s website for specific version details.

Deploy the CM WebClient Application in Liferay

Release the WAR file containing the CM WebClient application to Liferay deploy folder.

You might need to configure the Web.XML file to allow Liferay to recognize and load your application.

Install The Load Balancer

This document follows the method suggested by RAJU, Bharat (2014) to use Apache as a load balancer. Other possibilities exists and LIFERAY (2015) suggests two more

  1. Solution 1: Apache + mod_jk (
  2. Solution 2: Using Pen which is a load balancer for "simple" TCP-based protocols (Reference:

On RAJU, Bharat (2014)’s guide, follow all steps to install and configure the Apache Server. Once you complete those, check that the software is properly installed by opening a browser and typing the URL http://localhost which should display the following page with the message:

It works! :

Figure 3 – Results of Installing Load Balancer

Create Two Load Balance Nodes using Tomcat.

For these instructions, two nodes of Tomcat 7 were created using Apache server following the guide offered by RAJU, Bharat (2014) where binaries are downloaded from, a mod_jk.conf file is created and edited to define the Load Balancer workers, set Log level and additional parameters, and configure the two nodes.

These instructions were followed until the Apache Load Balancer is configured where confirmation can be seen where a green icon with a tooltip indicates ; ’Running all Apache Services’ as indicated on the image below (from Step 15 on the guide):

Figure 4 – Results from Apache Load Balancer

Set Up Load Balancing In Liferay Tomcat Server.

For this process, the instructions defined by IMPRADEEP.COM (2015) were followed where the main actions involved:

  • Unzipping Liferay Tomcat binary twice into two different folders
  • Modification of \Liferay_home1\liferay-portal-6.1.1-ce-ga2\tomcat-7.0.27\conf\server.xml to specify jvmRoute=”tomcatA” and jvmRoute=”tomcatB”
  • Changing the default Port Numbers in server.xml of tomcatB to avoid port conflicts with ports of Liferay_home1.
  • Uncommenting the lines in httpd.conf from Apache Conf directory to include such functionality
  • Modifying httpd.conf from Apache Conf directory to include the BalancerMember URLs and routes
  • Starting Apache server and both Tomcat instances

Cluster The Two Nodes in Liferay

This process considered the steps suggested by RAJU, Bharat (2014) to cluster the two nodes previously set up in Liferay Portal.

Follow details on "Clustering two nodes of Liferay –portal-6.1.1 –Ce-ga2 bundled in Tomcat 7" from RAJU, Bharat (2014) in the REFERENCES section of this document.

back to top

Testing Scenarios

Tomcat servers running in a Cluster with Apache server as a Load Balancer

  • Using Apache’s Load Balancer Manager, ensure both nodes in the cluster are operational:

    Figure 5 – Operational Status of Nodes

    : This test makes use of the Load Balancer Mode =mod_jk/1.240 which is displayed in the Load Balancer Manager

    Figure 6 – Verifying the Load Balancer

This setting allows Apache to function as a Load Balancer.

  • Verify that the first Liferay app server is running the WebClient application within Liferay by going to its URL which in this case is localhost:9081

    Figure 7 – Check the First Liferay App Server
  • Verify that the second Liferay app server is running the WebClient application within Liferay by going to its URL which in this case is localhost:9082:

    Figure 8 – Verify the Second Liferay App Server
  • Verify the application runs within the Load Balancer URL

Now we are going to enter the Load Balancer IP which will operate as a PROXI and execute the balancing:

Figure 9 – Enter the Load Balancer IP

Figure 10 – Set up the Balancing

The user doesn’t know what server is being accessed. The load balancer takes care of routing the call and masking the IP address.

  • Verify the routing process

It is possible to see what server is being routed to by checking on the Load Balancer Manager console from Apache Server:

Figure 11 – Check the Status of the Load Balancer

  • Simulate Server 1 Failure and Automatic Operation on 2

Now simulate a Server failure by shutting down the server on port 9081:

Figure 12 – Shut Down the Server

Refreshing on the Load Balancer Manager, we see such server is down (error state):

Figure 13 – Verify Error State

Now, back on the application, we can see the session is lost but if the application is refreshed, it continues running:

Figure 14 – Refresh the Application to Continue Running

  • Simulate Failure on Server 2 and Automatic Operation on Server 1

Simulate a second server’s failure and see how the connection is balanced.

First, bring up the 1st server.

Figure 15 – Simulate a Server 2 Failure

NOTE: The scripts used in this process to shut down and start up the servers are dependent on your hardware and software configuration and there is no generic process to include. However, the ones used for this test are included in the references section of this document.

Figure 16 – Both Servers Running

Shut down the 2nd server, node 2:

Figure 17 – Execute Shutdown

Figure 18 – Verify Error State

Back in the application we refresh and the application can run without any need to redirect to a different URL:

Figure 19 – Refresh Application

Figure 20 – Verify Apps Running on Node 1

We can see this is running on node 1 as there is more traffic to it. This is verifiable in the Load Balancer Manager Console:

Figure 21 – Load Balancer Status

The application can only be accessed via the Load Balancer’s URL:

Figure 22 – Load Balancer URL

And never had to know about the App Servers’ URL or IP Addresses.

back to top


back to top

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


Powered by Zendesk