Building a reliable, automatic scaled-out infrastructure for your web application is not a job for the faint of heart. It often involves deep knowledge of your application servers or getting expert consulting. Sometimes both. GigaSpaces XAP application platform will let you do that, and more, with just a few easy steps and at a much lower cost.

Starting from version 6.6 m1 of GigaSpaces XAP, one can deploy not only spaces and PUs (processing unit) but also web applications (WAR files).  Meaning, you can deploy many instances of your web application in order to meet heavy performance requirements. The best part is that the scaling out deployment can be done automatically and on-demand using GigaSpaces SLA configuration and based on application usage.

In this first installment I will show, from high altitude, how to deploy a web application (Spring Pet Clinic) using GigaSpaces Grid-Browser, and how to configure a load balancer (Apache HTTP server with Balancer module) in front of your multiple web application instances. In order to follow this demo please download the following:

  • Sample Web Application – The sample application (Spring Pet Clinic) is part of the Spring Core distribution and can be downloaded here. It includes the WAR file and a database folder. To execute the web application with its default settings, simply start the HSQLDB instance in the "hsqldb" directory using "server.bat 
  • GigaSpaces XAP – Early access versions of GigaSpaces XAP can be downloaded here. GigaSpaces XAP utilizes embedded Jetty (http://www.mortbay.org/jetty-6/) as web container and together with highly optimized resources pooling between web application instances (running on the same machine) it gains excellent performance.
  • Apache Configuration Files – Apache Web Server (2.2.9) and all related configuration files can be found here .

Starting the Grid

The first thing we need to do is to start our grid service. Our grid will contain one instance of a Grid Service Manager (GSM) and 2 instances of Grid Service Containers (GSC). The scripts to run the grid components can be found under the GigaSpaces XAP folder in the bin directory. To run the GSM, execute one instance the gsm script (gsm.bat for Windows or gsm.sh for Linux). To run the GSC, execute two instances of the gsc.bat gsc.bat for Windows or gsc.sh for Linux).

Starting the Grid Browser 

Once the grid components are up and running, we can start our grid browser. Run the gs-ui script from the bin directory (gs-ui.bat for Windows or gs-ui.sh for Linux). Click the "Deployments, Details" tab and within a few seconds you may see a visual presentation of our grid service. It should look like this:

Deploy the web application

Now we are ready to deploy our web application. First click on "Launch->SBA Application – Processing Unit…" on the main menu. Then click the "…" button next to the "Processing Unit" and select your WAR file. Type the number 2 in the "Number of Instances" field and the number 1 in the "Per VM" field. It should look like this:

Now click "Deploy". After a few minutes you should see the next window: 

Now you are ready to test your WAR deployment. Go to http://localhost:8080/petclinic and also to http://localhost:8081/petclinic and you should see the Petclinic home page. 

Configure load-balancing 

At this point we have two instances of our web application running on two different ports, 8080 and 8081; these ports are configured as default and are numbered according to the number of instances being deployed. However, although we have two running instances it is hardly scalable without load balancing and session stickiness (session affinity). In this section we will have our web application truly scalable in no more than a few easy steps.

First download and install Apache web server. In this demo I used Apache version 2.2.9 which can be downloaded at here

Our first task is to configure the Apache web server to function as a load balancer. The main idea here is to define some sort of a routing table so Apache will know how to route requests. Two main Apache modules should be enabled and configured; mod_proxy and mod_proxy_balancer.

Change the Apache config file (APACHE_INSTALL_DIR/conf/httpd.conf) as follows:

  • Enable modules  – mod_proxy.so, mod_proxy_balancer.so, mod_proxy_connect.so, mod_proxy_http.so, mod_rewrite.so, mod_status.so
  • Insert the following lines at the end of the httpd.conf file, save the file and restart the Apache web server:

RewriteEngine On

ProxyRequests Off

ProxyPass /balancer !

ProxyPass /petclinic balancer://localhost/ stickysession=JSESSIONID nofailover=On

ProxyPassReverse / balancer://localhost

ProxyPreserveHost On

<Proxy balancer://localhost>

BalancerMember http://localhost:8080/petclinic route=jetty1

BalancerMember http://localhost:8081/petclinic route=jetty2


#define the balancer manager

<Location /balancer-manager>

SetHandler balancer-manager


#define the status manager

<Location /server-status>

SetHandler server-status


Next, create a file called jetty-web.xml in your web application war file under WEB-INF folder and insert the following lines into it. This file tells Jetty to automatically append the instance number, together with the string "jetty", to the jsessionid parameter, which will take the form of: jsessionid=<session-id>.jetty<instance-number>. GigaSpaces deployment engine will make sure that every deployed instance will have a unique running number:

<?xml version="1.0"  encoding="ISO-8859-1"?>

<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">

<Configure class="org.mortbay.jetty.webapp.WebAppContext">

  <Get name="sessionHandler">

    <Get name="sessionManager">

      <Call name="setIdManager">


          <New class="org.mortbay.jetty.servlet.HashSessionIdManager">

            <Set name="WorkerName">jetty${clusterInfo.runningNumberOffest1}</Set>







The figure below illustrates how Apache load balancing manages sticky-session (session affinity) together with Jetty:


Web requests are directed by the Apache load balancer according to routed parameter (jetty1), which, in turn, was attached to the session id parameter by Jetty and was numbered by GigaSpaces deployment engine.


Now you are ready to scale-out our load-balanced web application. Repeat the above steps of starting the grid up until deploying your WAR file. Should everything go successfully; you can access your web application just by typing http://localhost/petclinic/index.jsp in your web browser. As part of the Apache proxy modules functionality, there is also a nice real-time application which allow you monitor real time activity on your web application instances. This tool is especial handy when you have machines with different specs and you want to direct the Apache Load Balancer to distribute requests by weighted factor in real time. The balancer application should be available at http://localhost/balancer-manager.


Compared to other solutions 

GigaSpaces XAP is a scalable, cost-effective alternative to traditional application servers and unlike traditional application servers, GigaSpaces XAP enables predictable application scalability on-demand. GigaSpaces XAP achieves predictable scalability on-demand by virtualizing all aspects of the application infrastructure: data, messaging, services (business logic) and deployment.

The table below lists the advantages of GigaSpaces XAP versus traditional middleware: 


Traditional Middleware


Seamless Scaling

Scaling is a complex process, requiring changes to code and architecture

Seamlessly integrate with existing development platforms. Scaling is achieved simply by adding application instances on-demand.

Predictable Scalability

Doesn't scale linearly; Consequently, hardware and software capacity is difficult to project leading to over- or under-provisioning

Scales linearly. Hardware and software requirements are predictable allowing just-in-time provisioning

Unexpected Loads

Scaling to handle unexpected loads is slow and error-prone, leading to failure (under-provisioning) or waste (over-provisioning)

Simply scales on-demand leading to optimized utilization of resources and peace-of-mind.


Middleware stack made of multiple tiers that require tight integration. Not only is this expensive and error-prone, it creates a scalability and performance bottleneck.

Middleware runtime that handles data, messaging and services, using a shared clustering and deployment model that can simply scale and recover.

Heterogeneous Environment

Will require multiple middleware products that need to be integrated leading to complexity and performance and scalability bottlenecks.

A single platform for Java, .Net, C++ and dynamic languages (e.g., JavaScript, Groovy, JRuby)



There are many tweaks and configuration tuning that can be done, which are not covered here, in order to customize the balancer to your needs. However, the main idea should be clear; you can have your web application scaled out almost with no effort at all, in order to meet your heavy traffic requirements. With easier configurations you can also use GigaSpaces SLA in order to have more instances deployed automatically at peak times (the Digg affect). 

Now, just as an exercise, try doing the same with WebLogic or WebSphere. I can assure you that even with the clearest manual, it will take you days to have your web application up and running, not to mention that on-demand scaling-out is not supported by any of them. At this point it is also important to mention that GigaSpaces is Amazon EC2 certified, which means that you can deploy your web application on Amazon EC2 cloud, and together with GigaSpaces SLA configuration you can be "virtually" independent of hardware when peak times demands scaling out.  Taking into account the cost of such a solution you might have a winning model in your hands.

In my next installment, I will elaborate more about how GigaSpaces SLA works and how to configure it to enable on-demand scaling-out web applications.

Scaling-Out Web Application with GigaSpaces XAP. Part I
Hanan Ben-Lulu
Tagged on:                 
  • Hi Hanan,

    These are really good news, I believe our client in the Web 2.0 and banner networks platforms will take advantage of this new feature

    Best Regards,
    Moshe Kaplan
    moshe.kaplan at rocketier.com

  • florin pop

    I don’t get it … how the on-demand scaling works… as far as i seen you do a static load balancing with apache… where is the on-demand scaling… gigaspaces xap advantage?

  • Hanan Ben Lulu

    Dear Florin,

    The on-demand scaling demo, including more nice features, is planed to be published on my next, part II, blog very soon.


  • Ankush

    None of the disadvantages listed for traditional middleware are true unless they have been used in the wrong way. Every disadvantage can hold true for Gigaspaces especially in this state where there are very few experts on Gigaspaces.

  • This isn’t good or bad. It’s just the way of things. Nothing stays the same.