Monday Feb 28, 2011

Shoal 1.5.29 released - GlassFish 3.1's runtime dynamic clustering service

As part of the tumultuous release of GlassFish 3.1 today which comes with clustering, centralized administration, high availability, improved automated delegated transaction recovery and a host of other features on top of the Java EE 6 platform,  I am delighted to announce the release of  Shoal 1.5.29 - the latest version of the Runtime Dynamic Clustering Framework library that is the underlying runtime clustering engine for GlassFish 3.1.

GMS is employed by many GlassFish modules for group communications and group lifecycle event notifications. GlassFish modules that use GMS include the HA (in-memory replication) module, the transaction service module, the IIOP Failover Loadbalancer, and EJB Timer Service (for timer migrations). 

The In-memory Replication module (also a part of Project Shoal ) is a caching backing store module built on top of Shoal GMS. The replication module is used in GlassFish for HTTPSession, EJB Stateful Session Beans state replication, and Single Sign-On state replication, and in addition, is also employed by Project Metro Web Services for making Reliable Messaging and Secure Conversations highly available in GlassFish 3.1 release. 

In this Shoal GMS release, we have a major change incorporated and that is the default transport provider for Shoal has changed from JXTA to Grizzly - specifically this release uses Grizzly version 1.9.28 as the transport provider. Grizzly gives us better performance with its NIO based transport - GlassFish 3.1 HA is about 34% improved over GlassFish 2.x in our internal benchmarks partly due to the move to use Grizzly as the transport under GMS with the HA module using GMS messaging APIs for its replication logic. Moreover,  the developers of Grizzly are co-located with and part of the GlassFish team allowing for faster support within the team. The JXTA 2.5 transport is still available via a source code build, however, since it is not tested as part of the extensive GlassFish 3.1 HA and GMS testing, it is not included in the pre-built shoal-gms jar. 

Additional features in this release include a new notification of the Master Change Event when the group master changes to another member when an existing group master fails or is shut down administratively. Another new feature is the REJOIN sub event as part of the JoinNotificationSignal and JoinedAndReadyNotificationSignal to symbolize a  use case where a member failed and restarted much before GMS's failure detection algo confirmed the failure - in such cases, a failure notification of the restarted member is confusing and hence a REJOIN sub event is sent in as part of the member's JoinNotificationSignal and JoinedAndReadyNotificationSignal. 

We hope and look forward to the community to continue giving its valuable feedback for improvements in the Shoal modules  - Please download Shoal as a library for use in your projects and give us your valuable feedback and RFEs for improvements. We welcome your feedback at users AT

You can download Shoal 1.5.29 library from here :

Thursday Oct 21, 2010

How To Configure & Test High Availability with GlassFish Server 3.1 Using A Single Machine

Update 02/28/2011 : GlassFish 3.1 shipped today with clustering, centralized administration, high availability and a host of new features providing these features on the Java EE 6 platform.  Get the download here.

The Shoal runtime clustering (Shoal GMS) and HA (Shoal Cache) team has been busy working on bringing GMS and In-memory replication capabilities to GlassFish Server 3.1 which is the release-in-development at the time of writing this entry. 

In this entry, I will describe steps to configure and test High Availability with GlassFish Server 3.1 and trust this will help the community and customers to run their own Java EE 5 or Java EE 6 apps with HA and give us feedback. 

Single Machine Step-by-Step instructions to setup cluster and HA 

So here are the steps doing the same on a single machine:

  • Download GlassFish 3.1 final build from here. Pick up either the full Java EE distro or web distro. Use either the zip distribution or the executable installer.  As a convenience, the latest promoted build is also aliased as latest-glassfish-<platform>.(sh/exe) or for the full Java EE distro while it is aliased as latest-web-<platform>.(sh/exe) or for the web distro.
    • <install_dir>/glassfish/bin
  • Ensure you have multicast enabled on your network and Shoal GMS and Cache can work in this environment. Run this on two terminals : 
    • ./asadmin validate-multicast 
    • This should show messages being sent and received between the two terminals and ensure that basic multicast support exists on your network.
    • Your messages would look like this in one of the terminals :
      • Will use port 2,048
      • Will use address
      • Will use bind interface null
      • Will use wait period 2,000 (in milliseconds)
      • Listening for data...
      • Sending message with content "" every 2,000 milliseconds
      • Received data from (loopback)
      • Received data from
      • Exiting after 20 seconds. To change this timeout, use the --timeout command line option.
      • Command validate-multicast executed successfully.
  • Run the command to start the domain : 
    • ./asadmin start-domain 
  • Next create a cluster using the command line interface : 
    • ./asadmin create-cluster <cluster-name>  
    • In the above step, the multicast address and port that Shoal GMS/Cache would use will be auto generated for you. If you want to set a specific multicast address and port of your choice for Shoal GMS to use then do this : 
    • ./asadmin create-cluster --multicastaddress 229.x.x.x --multicastport yyyyy 
      • where x is any integer between 0 and 254 and y is any integer over 1024 (if not a super user) for an available port  you choose. 
  • Next, create a couple or more instances belonging to this cluster : 
    • ./asadmin create-local-instance --cluster <clustername> <instancename>

      Note down the HTTP Port of each instance as you create them - you will need it when testing out failover. 

  • Next, start the cluster : ./asadmin start-cluster <clustername>
  • Check if the cluster started fine : ./asadmin get-health <clustername>  The get-health command reports data based on GMS's auto-discovery of the instances in the cluster as the cluster started up. You should see output similar to the following :
    • inst1 started since Thu Oct 21 14:45:10 PDT 2010
    • inst2 started since Thu Oct 21 14:45:19 PDT 2010
  • You can also use ./asadmin list-instances command to see if the clustered instances are running. 
  • Now you are ready to deploy an application and try out HA using the port-hopping technique to test failover without an LB. 
    • Note that you can do port hopping only when you are on single physical machine or when both the instances are on the virtual machine instance.  If going beyond a single machine, then you will need to front the cluster with an LB capable of sticky sessions and round robin 
  • Deploy the ClusterJSP application first, before you try your app, as it will help set a baseline with a GlassFish supplied ear file that is tested to establish a baseline that basic HA functionality is working. The clusterjsp file is here (will be part of samples soon) : 
    • ./asadmin deploy --availabilityenabled=true --target <clustername> <path-to>/clusterjsp.ear
    • The availabilityenabled flag is the only requirement in the deploy command to HA enable your application. Besides that, for a web application, you do need to add the <distributable/> element to the web.xml packaged with the application. This tells the web container that the application is ready to be used in a distributed system such as a cluster.
  • Access the first instance's URL on your favorite browser : 
    • http://<host>:<first instance port>/clusterjsp
  • The clusterjsp browser window should look like the following :

Note in the image above, the "Served from Server Instance : inst1" meta information that tells you that this page was served from the first instance "inst1" being the first instance's name.

Also note, that under the section "Data retrieved from the HttpSession:" there is an entry stating jreplicaLocation=inst2. This is a HttpSession Cookie that is sent back by the ShoalCache layer to the web container that forwards it to the browser that an LB could potentially use - that this session's replica instance is inst2. An LB capable of handling such information such as the latest upcoming version of GlassFish LB Plugin that works with the Oracle iPlanet WebServer, can failover to the exact replica instance on failure of a primary, thereby saving broadcast type network calls in the replication layer to find out which instance has a particular session to be resumed on this failover instance.  This is very useful particularly in larger clusters. 

  • Add some session data as a key and a value, Name of Session Attribute: John and Value:  Doe. 
The above page shows that first instance has saved the session data to the second instance and has it in the first instance web container's active cache. 
  • Now to simulate failover, you can port hop to the next instance or any random instance in your cluster, say second instance 
    • http://<host>:<second instance port>/clusterjsp
    • Before doing the above, you can optionally, stop the instance that served the first request i.e the first instance,  using 
      • ./asadmin stop-instance <instance name> command or 
      • find the process id of first instance  by using jps -mlvV | grep <instancename> and terminate the process using kill -9 <pid>
      • Run ./asadmin get-health command again to see the status of the cluster. You should see output similar to the following if you killed the instance :
      • inst1 failed since Thu Oct 21 15:17:47 PDT 2010
      • inst2 started since Thu Oct 21 14:45:19 PDT 2010
    • On the second instance's page you will see that the session data written on the first instance was saved in the cluster and retrieved when the page was loaded on second instance. The session was resumed on second instance. Your page would look similar to the following : 

Note above that the second instance served the page and the session data written by the first instance was retrieved from the replica cache by the replication module in second instance. Also note that the second instance has the first instance as its replica in this two instance cluster, but we know that instance does not exist any more as it was killed or stopped. 

  • At this point, any session data written from this page on second instance would not be highly available if you have a two instance cluster as the first instance is no longer around. 
  • Go the terminal window and restart the first instance ./asadmin start-instance <firstinstancename> 
  • Go back to the browser that has the page served from second instance and add some session data, ex. Name of Session Attribute : Jane, Value of Session Attribute: Doe. Your page should look like the following:

Note that session parameters Jane = Doe has been added to the session but the session should now be highly available as you have restarted the first instance and then written the session parameters on the second instance. 

  • At this time, simulate a second failover by porthopping to the first instance  http://<host>:<first instance port>/clusterjsp/HaJsp.jsp
  • Your page should look like the following : 

As you see above, inst1 retrieved all the session parameters and this shows the high availability of sessions in the two instance cluster. 

If all goes well as above, you now have a baseline with which to compare your experience when you deploy your own application to try out GlassFish 3.1 High Availability for sessions.

You can also try a cluster with 3 or more instances to see High Availability in action. You will also see that for each new session, the replication module chooses a different replica instance - this is a change from the buddy replication based mechanism with GlassFish v2.x High Availability feature. We will have a more detailed blog entry on this new approach later. 

With the above instructions, you should now be able to deploy your own application and if you see issues there and not with clusterjsp, this will give you a reason to investigate what is different with your application behavior that could contribute to the issue. Most often, the issue would be a non-Serializable object in your session that was working fine when you deployed to a non clustered single instance as there was no need to ship session objects to another replica instance. When the non-Serializable was involved in a distributed systems setup as in a cluster, issues start to show up. So look out for those situations. Start with scouring the server log for these indications. 

If you do see issues that you believe belong in GlassFish HA component, please send us feedback on the user list : users at glassfish dot dev dot java dot net 

You can also file issues at the GlassFish issue tracker  here.  GlassFish HA issues are filed under the "failover" subcomponent.

Wednesday Oct 28, 2009

GlassFish v2.1.1 and Sailfin 2.0 (Sun GlassFish Communications Server 2.0 ) released!

Great news out today that both the GlassFish v2.1.1 (Sun GlassFish Enterprise Server 2.1.1) and Sailfin 2.0 (Sun GlassFish Communications Server 2.0 ) have been released today. 

GlassFish v2.1.1 has over 200 bug fixes and improvements. On the high availability side, we have refined the replication module further and on the fault tolerance side, Shoal GMS Clustering (version 1.1) now leverages the GlassFish Node Agent's ability to detect process losses quickly to inform Shoal GMS Members about failures. This improved our software failure detection timeout from around 9-12 seconds to around 4-5 seconds - an important improvement in supporting failover and other recovery oriented computing components.  

Sailfin 2.0 introduces High Availability for SIP and Converged applications and uses an enhanced predictive replication algorithm supporting high traffic and large number of active sessions in addition to supporting Rolling Upgrade with session states retained. With many improvements in Shoal's clustering core along with support network traffic specification to specific network interfaces, and improved health state transitions, this makes for added reliability and scalability in the clustering capabilities of Sailfin. 

Congratulations to the entire Sailfin and GlassFish developer community for splendid work in successfully releasing these products. 


Friday Sep 25, 2009

How Does Sailfin (Sun GlassFish Communications Server) SIP Session Replication Module Select Replica Instances?

For scalable deployments of middleware with high availability, employing a session state persistence approach to persist session state to all instances in the cluster could be a sub-optimal solution. Replicating sessions to all instances in the cluster would result in significantly higher network traffic just for replicating state reducing bandwidth for growing application user requests. This approach of sharing sessions across all instances perhaps is suited for small clusters with limited number of concurrent requests.

One of the better approaches to use to secure scaling advantages is the approach of buddy replication. In this approach, each instance selects one (or more) other instance(s) in the cluster to replicate any and all of its sessions. This is a superior approach and in fact, works for fairly large deployments. There are factors to consider here, in terms of the overhead the replication subsystem will need to handle at the cost of performance particularly when large number of concurrent sessions are being processed and later expired. An overhead to consider is the need for instances to form ring-like replica partnerships based on a certain order in which buddies would be available and selected. When a buddy instance fails, there is the cost of re-adjusting and forming new buddy relationship with another surviving instance, and when the original buddy recovers, to re-adjust again to use this upcoming instance as a replica partner by one of the instances in the cluster. Think of this as a chain based ring with its links randomly being removed but with the consistent goal of retaining a connected chain ring with the overhead of relinking each time a link is removed or added or a new one added to the chain.

There is also cost to be considered (if such were the design approach), each time the cluster shape changes for dynamically changing/updating any cookie information pertaining to replica locations that could be sent back as part of the response headers to the LB - typically that cost should also be avoided through more efficient means.

In the case of GlassFish, we have fairly successfully used buddy replication with each instance having a single replica buddy. We use the approach of locating sessions in the cluster when a request is directed by the LB to any random instance when a failure of an instance that was processing requests occurs. This has worked well for reasonably large mission critical environments where the scalability and availability requirements are within the boundaries of this approach.

In Sailfin 2.0, scaling and reliability needs for telco applications is typically very high and we needed a scalable approach to ensure Sip Session Replication overhead sustained good performance with the added reliability and availability. We, therefore, used a consistent hashing algorithm to dynamically assign a replica instance for each new session. This we did by leveraging the consistent hashing mechanism that the Sailfin Converged Load Balancer (CLB) uses for proxying requests to a target instance using a BEKey. In the case of replication, the same logic of using a hashed key for the target instance assignment is taken a bit further.

For replica selection, for each new session, we pre-calculate the most likely target instance that the CLB would failover to, if the current target primary instance that would serve the session, were to fail in future. This gives us the instance to which, the current primary instance, should replicate to. This gave us significant benefits in that there were no client cookie updates required to include replica partner information dynamically. There was no readjustment of replica partnerships needed when a particular instance failed as the hashing algorithm would provide another instance to replicate to with just an API call. When the failed instance comes back into the cluster, the sessions that were owned by it in its prior incarnation that are unexpired, would migrate back to it to maintain a balanced set of sessions across the cluster. And the replica selection algorithm would assign the original failover instance for this primary, as the replication partner.

Since this is based on a hashed selection algorithm with predetermined failover target, replica selection is dynamic, and does not need the knowledge of a particular order of instances being ready in the cluster to point all sessions from another instance as a replication partner. And more importantly, as the failover occurs to the specifc instance where replica data is located, there is significantly less network overhead to locate any particular session in the cluster when a particular request within the session scope is sent to the CLB. This allows for more bandwidth being available for a larger number of user sessions to be served. This approach is thus superior to the buddy replication approach and helped us scale to higher throughput and sustain a larger number of long running sessions.

It must be emphasized here that system level, and application server level tuning, and sizing are essential to ensure sustained performance, scalability and reliability in addition to the improvements provided with the SSR replication scheme and other parts of the Sailfin v2 server (aka Sun GlassFish Communications Server 2.0) .

As always, we welcome your feedback and encourage you to try Sailfin and send us any inputs and questions you may have in this respect.

Sailfin Promoted Builds are available here : Sailfin Downloads

Sunday Jun 21, 2009

GlassFish Clustering: Meaning and impact of configuring attributes of group-management-service element ?

Based on a query from one of our field colleagues, I added an FAQ entry on the meaning of the group-management-service element attributes  and impact of changing the default values as this is not yet covered by our official documentation (it will be updated with this information soon).

These configurational attributes determine Shoal GMS's behavior with respect to Discovery and Health Monitoring of cluster instances in a GlassFish cluster. It is very useful and important to understand these underpinnings of GlassFish's runtime clustering engine.

Here's the FAQ entry :

Friday Oct 24, 2008

New Shoal Update : Shoal 1.1 bits updated to promoted build 10212008

Shoal 1.1 bits on the Shoal download site have been updated to reflect the promoted build dated 10/21/2008.  We are getting close to releasing Shoal 1.1 sometime in late November.

Get the latest promoted build here.

We have also added a buildable Source and Javadocs zip distribution corresponding to this promoted build on the download page based on a community user request.

A number of fixes went into Shoal during this time (from the prior promoted build of 08202008). Read the announcement here for changes that went in.

Project Shoal benefited not only from the Shoal user community feedback but also the intensive testing that is ongoing for the upcoming Sailfin v1 release in December. As a Telco appserver, Sailfin provides the ideal testing ground for intensive clustering features. Truly where the rubber hits the road.

Thanks very much to Sheetal, Joseph Fialli, Mohamed Abdelaziz, Bongjae Chang, Sailfin and GlassFish Quality Engineers Kazem, Sony and Varun, and most of all the Shoal community members.

As always, we value your feedback so please do continue sending us feedback to help improve Shoal and to address your needs with Shoal clustering. 

Tuesday Oct 21, 2008

Economic woes resulting in slashed tech budgets? Sun's GlassFish+MySQL makes perfect sense

With signs of a global economic turmoil underway, the financial system is under severe stress with credits vanishing, and Government Departments, small and medium businesses, and large corporations are faced with potential budget cuts for technology spending. Case in point :

With Sun's open source "stack" and cost-effective support subscriptions, affected sectors of the economy can take advantage of standards based, high quality, open source software with the low cost support services from Sun. This is a good time to consider moving away from expensive proprietary software stacks to Sun's open source software.

Take the case of Sun's commercially supported GlassFish + MySQL offering, both rock solid products that come with features only available in high cost closed-source products. This offering provides you the opportunity to seamlessly move from expensive licenses to an annual support subscription based offering that will reduce your cost of ownership. For example, Unlimited deployment of GlassFish + MySQL starts at $65,000. GlassFish + MySQL constitutes a very compelling offering that will help you justify the move both on features and costs.

Contact Sun to find out how you can save significantly with this offering.

For more on the value proposition, read Arun's blog entry here.

Tuesday Aug 26, 2008

Shoal 1.1 bits updated for a new promoted build

The Shoal team has been busy addressing the needs of major projects such as Sailfin for a while now. It had been a while since we updated our promoted build for download with the latest and greatest fixes.

We have now promoted a new build for Shoal 1.1 and download bits are available here :

The announcement has more details on what went into this promoted build : 08202008 Promoted Build Announcement

We would welcome your feedback, issue reports and enhancement requests to make Shoal more useful for you.

Do send us your feedback at the Shoal user mailing list.

Tuesday Jun 03, 2008

Eclipse IDE GlassFish Plugin : Give us your feedback

Did you know that GlassFish community provides an Eclipse plugin for developers using Eclipse as their primary development tool ?

The plugin has been developed for a while providing basic integration with GlassFish. We now would like to make this integration more effective and useful to you to enhance your productivity when using GlassFish.

We would like to hear from developers on your experience (both positive and constructive) so that we can prioritize on making improvements. Our goal is to make life a lot easier for developers when using Eclipse with GlassFish. Community feedback is the best way we can learn how to make improvements. Of course, we also very much welcome any contributions from you to make improvements.

The plugin is available at the GlassFish Plugins Project Page.
Please send us your feedback and/or contributions at either the GlassFish users mailing list or at the GlassFish Plugins users mailing list.

Friday May 09, 2008

JavaOne2008: Shoal Mini Talk at Java.Net Community Corner

At the JavaOne pavilion, had set up a community corner where mini talks were given by various interested project leads. I gave a short talk on Introducing Shoal clustering framework. 

The audience was \*very\* small  but I had quality questions from one very interested participant who wanted to use Shoal as a Distributed Test Harness engine. Very unique use case I thought and yes, Shoal would fit that bill.

Here's the short slide deck of the mini talk: Shoal Mini Talk JavaOne 2008


Friday Apr 18, 2008

New Shoal Clustering Download Page

With a view to helping our users choose the right download, we have organized the Shoal downloads page on the lines of the GlassFish download page. The new download page is located here :

This should make it easier for users to find Shoal bits and use them in their clustering applications.We are seeing increasing interest from users with different types of questions in the Shoal user mailing list ranging from newbie questions to very advanced ones. Keep'em coming folks.

We will be posting new promoted downloads  and releases through this download page. Let us know if you need specific improvements to be made.


Wednesday Mar 12, 2008

GlassFish High Availability Session at Sun Tech Days Hyderabad

At the recent Sun Tech Days event at Hyderabad, I gave a talk covering GlassFish's High Availability features, particularly the In-Memory Replication support, as part of GlassFish Day (Feb 29th). 

I had the privilege of talking to a full house of around 500 people. The session covered introduction to HA, how easy it is to create, and configure a cluster of instances, and to configure the application for enabling in-memory replication based availability. The session elicited very good questions ranging from the basics to involved ones in the area of sizing the heap to sticky sessions support. I spent an hour after the session outside the hall answering questions posed by interested folks from several companies.

Many attendees wanted to get a copy of the slide deck. Look here for it.

Needless to say, we would very much appreciate any feedback or questions on GlassFish's High Availability. Please send these to us at the GlassFish user mailing alias.

Tuesday Mar 11, 2008

Notes from GlassFish Booth at Sun Tech Days, Hyderabad '08

I am back after a two week visit to India. I took the week off last week to be with my folks and to unwind and recharge in my home city, Mumbai.

The week before that was an incredible one for me as I saw the hi tech boom in India first hand. The swelling and enthusiastic crowds at the Sun Tech Days event at Hyderabad on Feb 27, 28 and 29 was very thrilling to experience to say the least. The event was highly successful in attracting budding youngsters and experienced professionals alike. I am told that the content of the event was very fulfilling for attendees.

Some notes of interest :

  • Each session had between 1000 and 1500 attendees. Community Day was on Feb 29th with tracks such as GlassFish, OpenSolaris, Netbeans, etc. and each track had an expected 450 people based on hall capacity. In the GlassFish track, we saw that increase to around 500.
  • At the GlassFish booth, I met quite a lot of visitors many of whom had either vaguely heard about GlassFish or never heard of it. About a 3rd of people were ones who work with an Application Server in a professional capacity. Others were developers learning the ropes at work or students who were excited to see an open source appserver like GlassFish.
  • GlassFish is relatively new here - people have heard about it and are now beginning to try it out. So this was a huge opportunity to spread the word about GlassFish as a compelling open source project delivering a fully Java EE 5 compliant application server packing a whole bunch of features that commercial vendors usually provide for the cost of an expensive license and services attachment.
  • Common theme of questions from professionals were on availability of migration tools to move from BEA, and Websphere. They are looking for detailed documentation and engineering services support for migration to enable them to recommend GF in their orgs and in their client orgs. We are working on this on multiple fronts and through the migrate2glassfish project.
  • Many professionals I talked to had tried JBoss before but due to their employer or customer platform preference, they were on WebSphere or WebLogic.
    They were impressed with GlassFish's Administration ease of use and GlassFish's published SpecJ numbers.
  • Companies from which people came to booth read like the who's who of the hitech majors' list such as Wipro, Satyam, Infosys, Cap Gemini, etc.
  • Most users were still developing on J2EE 1.4. Many are beginning to move to Java EE 5.
  • Many developers I met were on Eclipse. I demoed GlassFish and NetBeans 6.0 when possible at the booth and many went back saying they will surely try NB with GF.
Based on reactions and questions that came from people at the booth, here are the things that I thought attracted many of these folks to think of converting from their existing middleware to GlassFish : 


  • GlassFish's open source status
  • Free for development and deployment
  • No license fee for product purchase
  • Strong community support
  • Sun's backing and commercial support offering (the concept of indemnification was new for some but many understood impact for their customers abroad)
  • Administration ease of use
  • Market leading product differentiators such as Grizzly, Virtual server support in Web tier, Web Services support, Easy cluster creation and management, Call Flow Monitoring, High Availability Options through In-memory replication and HADB, Inclusion of a quality MQ product, Netbeans and Eclipse IDE integration, etc.

Many of the professionals working with other application servers said the Administration, Clustering, High Availability, Loadbalancer support, Webservices support, migration support, and IDE integration would motivate them to try out or switch to GlassFish. 

Looking forward to hearing from these new GlassFish users at our user community mailing list.




Thursday Jan 17, 2008

Sailfin drives a new feature in Shoal: JoinedAndReadyNotificationSignal

As usage of Shoal's clustering framework increases across products, new feature requests are coming in to enrich Shoal's offerings for employing applications.

The Sailfin project is building a Telecommunications Application Server with contributions from Ericsson and Sun. One of the parts of Sailfin is a Java based load balancer called ConvergedLoadBalancer (CLB). The CLB load balances both Http and SIP based requests. The CLB is unique in that it is a component of the Sailfin appserver instance. Thus, any instance in the cluster can be configured as a load balancer. Such an instance can be part of a Front End LB Cluster performing load balancing of requests on a separate application server cluster tier or it can be part of a Self LoadBalancing Cluster wherein one or more instances of the application server cluster also perform the role of a load balancer while also serving requests. The CLB component and other Sailfin components employ Shoal for cluster events, messaging and health monitoring.

The CLB (as with any load balancer) needs to know when instances of a cluster have not only joined a cluster but also when the instances are ready serve requests. Shoal was up until now providing a JoinNotificationSignal which would be triggered as soon as each instance in the cluster used Shoal's GMS to join the cluster. This was sufficient for many use cases but for the LB it needed to know not just that but also when the instance had completed startup operations. This requirement helped us design a new notification called JoinedAndReadyNotificationSignal that would be disseminated to the cluster members for each instance completing startup and reporting such a completion to the group.

Shoal's GroupManagementService provides a new API called reportJoinAndReadyState() which the employing parent application can now call when the parent application has completed its own initialization and startup indicating a point where operational activities on the instance can now start.

Sheetal and I recently committed the code supporting this new feature.

This feature can be particularly useful while building Compute Grid and Cloud Computing type services using Shoal wherein each Grid node can now report when they are ready to act as nodes in the grid. BTW Shoal's concept of  a GroupLeader ties in well with the Grid's Compute Task Manager abstraction and is a good infrastructural fit.

Do please share your feedback with us at users alias about what you would like to see added in Shoal to serve your clustering and fault tolerance needs. Shoal's goal of clustering goes much beyond the realm of Data Grids (which we are looking into building ) with a wider  spread in terms of building fault tolerance solutions.

Friday Jan 11, 2008

GlassFish Hidden Nugget: Automatic Distributed Transaction Recovery Service

GlassFish v2 and v2 ur1 releases (and later) have support for transaction recovery (both manual and automated) in the sense that incomplete transactions at the time of an instance failure can be committed either manually or automatically.

Part of the new feature set in the cluster profile is a little known feature called Automated Distributed Transaction Recovery that comes out of Project Shoal's support for it. 

Essentially, Automatic Distributed Transaction Recovery in GlassFish works as follows :

Consider the following :

  • a cluster of three instances : instance1, instance2, and instance3
  • Two XA resources used by each GlassFish instance
  • a transaction starts on instance 1,
  • Transaction Manager on instance1 asks resource X to pre-commit,
  • Transaction Manager on instance1 asks resource Y to pre-commit,
  • Transaction Manager on instance1 asks resource X to do a commit,

Now, instance1 crashes

The Transaction Service component in one of the surviving members, instance2 and instance3, gets a notification signal that a failure recovery operation needs to be performed for a instance1. This signal from Shoal is called FailureRecoverySignal.

This notification signal comes to the Transaction Service component in only one particular selected instance as a result of a selection algorithm run in Shoal's GMS component that takes advantage of the identically ordered cluster view provided to it by the underlying group communication provider (default provider is Jxta).

The Transaction Service component in this instance, say instance2, would now go into its autorecovery block. It starts by waiting for a designated time (default to 60 seconds) to allow for the failed instance1 to start back up.

If instance1 is starting up, its own Transaction Service component would do self recovery to complete phase 1 transactions.

In instance2, after the wait timeout occurs, the transaction service component would now see if instance1 is part of the group view and if not try to acquire a lock for the failed instance's transaction logs through Shoal's FailureRecoverySignal and if successful (indicating that the failed instance did not startup), acquire the transaction log and start recovery of transactions i.e complete the commit operations for the pre-commit transactions. If the acquisition of the lock fails, then it gives up, and checks that the failed instance did startup through Shoal's group view and logs this fact.

If, during the recovery operations  being performed by instance2, the failed instance1 starts up, the transaction service component in this instance would first check with Shoal if a recovery operation is in progress for its resources by any other instance in the group and if yes, it waits for the recovery operations to be completed and then completes startup. This ability to check for such recovery operations in progress is through a related Shoal feature called Failure Fencing[1].  If there are no recovery operations in progress, then the startup proceeds with a self recovery which recovers any incomplete transactions in instance1's logs.

Now during recovery of instance1's transaction logs, instance2 fails, then the fact that this instance was in the process of recovering for instance1 is known to the remaining members of the group (i.e. instance3) through the failure fencing recovery state recorded in Shoal's Distributed State Cache. As a result, when instance3's transaction service gets the failure recovery signal, not only does it get it for instance2's failure, but also for instance1. This facility covers for cases where cascading failures or multiple failures occur.

Note that, for the automatic distrbuted transaction recovery to work, access to the transaction logs for all instances in the cluster for
purposes of auto recovery requires that the logs be mounted on a shared/mirrored disk[2].

[1] More on Shoal's Automated Delegated Recovery Selection
[2] Distributed Transaction Recovery





Shreedhar Ganapathy


« July 2016