GlassFish - World's first Java EE 7 Application Server


Web container and EJB High availability demo

This demo is aimed show casing the high availability features in GlassFish 3.1 open source edition. The demo will show modified attribute http session replication as well as transaction check pointing in EJBs. For purpose of this demo the following script will create a 4 instance cluster on the same node.

Team

  • Mahesh Kannan
  • Rajiv Mordani
  • Shing Wai Chan

Cluster creation

The following shell script can be used to create the cluster or the cluster can be created via the Admin Console as is demoed in this milestone (MS4). You must set GF_HOME environment variable and the <system ip address> in the script below before invoking the script.

#!/bin/sh +x

$GF_HOME/bin/asadmin start-domain
echo "domain started"

GF_CLUSTER_NAME=`uname -n`-cluster
echo Cluster name is $GF_CLUSTER_NAME
$GF_HOME/bin/asadmin create-cluster --multicastport 2231 --multicastaddress 228.9.1.3 ${GF_CLUSTER_NAME}

# how to turn on ShoalLogger to FINE logging using CLI.  The names below are subject to change in future but what will work now.
#$GF_HOME/bin/asadmin set-log-level ShoalLogger=FINE:javax.org.glassfish.gms.org.glassfish.gms=FINE:

# need to set unique GMS_LISTENER_PORT when running multiple instances on same machine.
# no need to set GMS_LISTENER_PORT when running one instance on each machine (includes DAS running on its own machine)

GF_DAS_HOST=localhost
GF_DAS_PORT=4848

for GF_INSTANCE_ID in 1 2 3 4
do 
$GF_HOME/bin/asadmin --host ${GF_DAS_HOST} --port ${GF_DAS_PORT} create-local-instance 
--cluster ${GF_CLUSTER_NAME} --systemproperties  ASADMIN_LISTENER_PORT=${GF_INSTANCE_ID}4848:HTTP_LISTENER_PORT=${GF_INSTANCE_ID}8080:
HTTP_SSL_LISTENER_PORT=${GF_INSTANCE_ID}8181:JMS_PROVIDER_PORT=${GF_INSTANCE_ID}7676:
IIOP_LISTENER_PORT=${GF_INSTANCE_ID}3700:IIOP_SSL_LISTENER_PORT=${GF_INSTANCE_ID}3820:
IIOP_SSL_MUTUALAUTH_PORT=${GF_INSTANCE_ID}3920:JMX_SYSTEM_CONNECTOR_PORT=${GF_INSTANCE_ID}8686:
BIND_INTERFACE_ADDRESS=<System IP address>:GMS_LISTENER_PORT-${GF_CLUSTER_NAME}=${GF_INSTANCE_ID}9490 inst${GF_INSTANCE_ID}

done

$GF_HOME/bin/asadmin start-cluster ${GF_CLUSTER_NAME}

echo Cluster created and started.
$GF_HOME/bin/asadmin list-instances

Cluster SSO setup

echo AS_ADMIN_USERPASSWORD=javaee > x.pwd
asadmin create-file-user --target ${GF_CLUSTER_NAME} --authrealmname file --passwordfile x.pwd --groups javaee javaee
asadmin set ${GF_CLUSTER_NAME}.http-service.virtual-server.server.sso-enabled=true
asadmin set ${GF_CLUSTER_NAME}.availability-service.web-container-availability.sso-failover-enabled=true

Note that one need to restart the cluster here. We suspect this is a dynamic reconfiguration bug.

Once you have setup the cluster with SSO, you can deploy two secured applications for SSO with availabilityenabled as follows:

asadmin deploy --target ${GF_CLUSTER_NAME} --availabilityenabled=true a.war
asadmin deploy --target ${GF_CLUSTER_NAME} --availabilityenabled=true b.war

HA SSO Demonstration

Once you have the cluster setup - deploy the attached application to the cluster with the availabilityenabled parameter set to true as shown below.

asadmin deploy --target <target-cluster-name> --availabilityenabled=true SFSBDriver.war

The application SFSBDriver is what shows the HA features in MS3. To start the demo - point your browser to

http://localhost:18080/SFSBDriver/SFSBDriverServlet (we are pointing to instance 1 but you could use any instance. Also replace localhost appropriately)

The application puts the following attributes in the HTTP session -

an Integer value
a String
and two stateful session bean references.

When the application is loaded on the browser hit refresh a few times and you will see that the counter is incremented.
Now shutdown the instance on which you were loading the page, in our case instance 1 as follows - 

asadmin stop-instance inst1

Get the session id for the cookie from the browser (on firefox right click on the page and select Page Info and you will get the session id).

Now redirect the browser to go to instance 3 - passing it the JSESSIONID=<session id> in the url.

So the url will be 

http://localhost:38080/SFSBDriver/SFSBDriverServlet?JSESSIONID=<session id>

You will observe that the counter increment continues from where you left off on instance1. The session data is replicated to inst3 and the state is preserved.

The [^SFSBDriver.war] is attached (sources will also be put up shortly). Click on Tools on the top right corner of this page to get to the attachments.

High Availability of Stateful EJBs using Method Checkpointing

Once you have the cluster setup - deploy the attached application to the cluster with the availabilityenabled parameter set to true as shown below.

asadmin deploy --target <target-cluster-name> --availabilityenabled=true SFSBMethodCheckpointDriver.war

To start the demo - point your browser to

http://localhost:18080/SFSBMethodcheckpointDriver/SFSBDriverServlet (we are pointing to instance 1 but you could use any instance. Also replace localhost appropriately)

The application puts the following attributes in the HTTP session -

an Integer value
a String
and two stateful session bean references. The first bean has a method called incrementCounter() which has a (default) transaction attribute (TX_REUQIRED). This causes the bean's state to be checkpointed at the end of Tx. The second bean has the same method incrementCounter() but that method has a transaction attribnute TX_NEVER. This means that invoking the icnrementCountER() will not cause the bean's state to be captured. In order to do this we have another method called doCheckpoint(). The method has been marked as checkpointed method using sun-ejb-jar.xml.

When the application is loaded on the browser hit refresh a few times and you will see that the counter is incremented.

Get the session id for the cookie from the browser (on firefox right click on the page and select Page Info and you will get the session id).

Now redirect the browser to go to instance 3 - passing it the JSESSIONID=<session id> in the url.

So the url will be 

http://localhost:38080/SFSBMethodCheckpointDriver/SFSBDriverServlet?JSESSIONID=<session id>

You will observe that the counter increment continues for sfsb1 from where you left off on instance1. But the counter for SFSB2 starts from 3 since that bean's state never got checkpointed after the thrird access.

The [^SFSBMethodCheckpointDriver.war] is attached (sources will also be put up shortly). Click on Tools on the top right corner of this page to get to the attachments.

Acknowledgement: I would like to thank Cheng Fang for his valuable help in getting this feature done. Many thanks for Joe Fialli, Bobby and Seteve (HA team) for their help.