Thanks to Gopal Jorapur for  his valuable input.

EJB Data Availability in Glassfish

Running the sample
Dynamic cluster support

Share my experience on EJB Availability in GlassFish. We are going to show a simple Stateful Session Bean application deployed on a GlassFish cluster and show how the SFSB data survives across failovers.

High availability applications and services provide their functionality continuously, regardless of hardware and software failures.

GlassFish provides High Availability Service for following components
HTTP Session Availability
JMS Availability
RMI-IIOP Loadbalancing and Failover

Http session availability is explained here, JMS Availability is explained in this doc

In this blog, we are explaining the EJB Data Availability, the sample uses Appclient container for RMI-IIOP Loadbalancing and Failover


        Download GlassFish V2 UR2 build from here.   (At the bottom of the page, download links are available, please pick the build for your platform)
        to install glassfish and configure cluster.

java -Xmx256m -jar  ./glassfish-installer-v2.1-b35-sunos.jar


        Following instructions are from  "setting up one machine cluster" from here
cd glassfish
             chmod -R +x lib/ant/bin
             lib/ant/bin/ant -f setup-cluster.xml
             cd ${glassfish.home}/bin
             asadmin start-domain  domain1
             cd to ${glassfish.home}/samples/quickstart/clusterjsp
             ${glassfish.home}/bin/asant  setup-one-machine-cluster
             ${glassfish.home}/bin/asadmin start-cluster cluster1

Our cluster is up and running now with two applciation server instances named instance-ONE and instance-TWO

Now lets configure the appclient

In this example we will be using the appclient  script from $AS_HOME/bin along with the sun-acc.xml from $DOMAIN_HOME/config/sun-acc.xml.  There is also a package-appclient script  to install appclient separately. This will be useful for installing appclient on seperate machines to drive the load.

Now we need to find out atleast one IIOP_LISTENER_PORT  to configure sun-acc.xml. To know the IIOP_LISTENER_PORT of a particular instance, type in the following command

    ${glassfish.home/bin/asadmin get instance-ONE.system-property.IIOP_LISTENER_PORT

edit ${glassfish.home}/domains/domain1/config/sun-acc.xml  as following

       Replace the port no with the one we got from asadmin get command
                 <target-server name="hostname" address="hostname" port="3700"/>
       Add the following line after the target-server line
                 <property name="com.sun.appserv.iiop.loadbalancingpolicy" value="ic-based"/>
       Edit the log-service line and fill in the absolute path for the log file
                 <log-service file="/export/home/space/appclient/bin/appc.log" level="INFO"/>


Get the src and application ear file

${glassfish.home}/bin/asadmin deploy   --host hostname --port 4848  --type application --target cluster1 --retrieve ./  --availabilityenabled=true  ${ear_file_location}/SFSB.ear

Now lets talk about two deployment options we used
The first one is "--availabilityenabled=true" - this is to specify high availability for our application.

High Availability is achieved by storing session state in a persistence store. There are three types of persistence stores are supported in GlassFish

            1. HA (used HADB as the persistence store)
            2. File  (used flat file system for persistence store)
            3. Replicated (same as in-memory, uses replication as persistence store)

We are using in-memory persistence in this sample. The cluster is configured for in-memory by default (No additional configuration required!)

At the high level, the replication works in a ring topology, basically each instance replicates its session/ejb data to its buddy instance. More about  this architecure can be found here

The second deployment option of interest is "--retrieve ./"  - this option is to tell the system that we expect a client jar and we need that jar to be copied in the current directory

More information about GlassFish Application Client Container can be found here

Running the sample

         As the application is deployed on the cluster, the bean is available on both the instances of cluster.

         The client looks up the bean in one of the instance (determined by the appclient container in a round-robin fashion)  and it has options to add,delete, print attribute operations on the bean.
         In this example we first add an attribute (name, value pair), then we will stop the instance that served this request. Add another attribute from the same client, this time the bean will be reconstructed in the second instance and the previous data is also recovered. This explains data availability across failovers.

         Now lets start the appclient
          ${glassfish.home}/bin/appclient -xml   ${glassfish.home}/domains/domain1/config/sun-acc.xml  -client ./SFSBClient.jar

          Bean Lookup Successful
          Add an Attribute(a)
          Remove an Attribute(r)
          Print Attributes(p)

          type option 'a'  , type in name and value of the attributes.

          Enter name :abc
          Enter value :123
          Attribute abc added on instance: instance-ONE

          After entering the attribute value, Client will tell us in which instance the bean is residing.
          Open another command window, stop this instance

         ${glassfish.home}/bin/asadmin stop-instance instance-ONE

         continue adding one more attribute by typing in 'a'
          Enter name :cde
          Enter value :456
          Attribute abc added on instance: instance-TWO

         now select 'p' to print the existing attributes.

          Name : abc, Value: 123
          Name : cde, Value: 456

          instance-ONE was replicating to instance-TWO, so the bean data from ONE was replicated to TWO.
          while adding the second attribute, client first tries to access the instance-ONE(to maintain stickyness),  since the instance was down, there will be a connection failure exception.
          (please see in appc.log, location defined in sun-acc.xml)
          Then the client tries to connect to instance-TWO and succeed

          type in 'q' to quit

          Now we know that the EJB data is replicated to some other instance. this is some what a costly operation so we dont want to do it often.
          There are two ways to tell the ejb  container that we need the bean state (data) to be saved at the time.
          1.marking the business method of a bean for checkpointing
          2. marking the business method of the bean to be run inside of a transaction (Data is by default saved at the end of the transaction)

          This sample uses transaction to initiate the save. This is achieved by  declaring  'addAttribute()'  business method of  the bean as transactional (pls see the source)
                                                 public String  addAttribute(String name,String value)

Dynamic Clustering
        You can add more instances to the setup and try the sample again. the available IIOP_PORTs are dynamically identfied pls see the following line in appc.log this will list all the available urls
                    INFO: corbaloc url ==>iiop:1.2@hostname:33702,iiop:1.2@hostname:33702,iiop:1.2@hostname:33700


1. During Configuration step, If the following command fails
       ${glassfish.home/bin/asadmin get instance-ONE.system-property.IIOP_LISTENER_PORT

       Then please try
                   ${glassfish.home/bin/asadmin get cluster1-config.system-property.IIOP_LISTENER_PORT

2. If you see CORBA connection exception during second add attribute, most probably log location could be wrong. The exception is expected, since the instance is down



Can you use this description if the client is a webclient?
I guess you are not able to use it.

Posted by Ferenc_Turi on June 09, 2008 at 04:05 PM PDT #

Yes you are right , these instructions are for Appclient Container only.

Posted by guest on June 10, 2008 at 05:13 AM PDT #

Hello Vivek,

In the above workflow, I see that you have packaged the stand alone client in the deployed SFSB.ear. So when you generate client side stubs for your beans you also get the EJBClient class file.

But how does this work when you have not packaged your client in the deployed application?


-- I deploy some beans into my GF cluster.

-- I generate the client stubs for those beans and take the client JAR to the machine on which I want my stand alone Java program to run.

-- I write my stand alone Java program.

--Running my stand alone Java program like this:

appclient.bat --client my-client.jar --mainclass MyStandAloneProgram

What parameter to the appclient.bat takes the stand alone java program's class?



Posted by Shreyas Shinde on July 23, 2008 at 11:23 AM PDT #

pls see
for running stand alone client

Posted by Vivekanandh Sedhumadhavan on December 03, 2008 at 06:35 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed

Vivekanandh Sedhumadhavan


« June 2016