GlassFish v2 Milestone 4 includes Shoal

GlassFish v2 has reached its Milestone 4 which is the Hard Code Freeze for the Beta. During this time, we addressed many bugs and features in Shoal and delivered a stable version to GlassFish

Shoal gets autoenabled when a cluster is created (Of course, one can disable it by setting the cluster's heartbeat-enabled attribute to false). When a cluster is created, the Domain Admin Server creates an instance of this cluster as a group and joins it as a Spectator member. So for each cluster, the Domain Admin Server participates as a Spectator member.

After instances are added to cluster and as these are started, each instance in the cluster participates in this Shoal cluster and can then communicate with each other and monitor each other's state. When an instance or cluster is shutdown administratively, Shoal notifies all instances about this impending shutdown allowing Shoal GMS client components within each instance to do appropriate pre-shutdown operations. Similarly, when an instance fails, Shoal notifies client components in all surviving instances about this failure and if needed to notify the need to perform any recovery operations. Details of these features are available at the Shoal site.  

Shoal is used in GlassFish for group membership monitoring and for value add features like automated transaction recovery performed by a delegate instance, self management wherein administrator can define remedial actions based on occurence of events including group events that Shoal notifies. The IIOP Load Balancer uses Shoal for dynamically generating failover IIOP end points as cluster shape changes and provides this to IIOP clients out-of-band so that these have updated failover targets. The In-Memory Replication component uses Shoal to confirm failures and to determine when a member has joined or gracefully left the group.

By GlassFish FCS, we will make Shoal stable enough to be released on its own as a standalone infrastructural component that other projects/products can use.

Shoal presents some interesting product use cases.

An in-memory cache on the lines of memcached should be a little more work and is a good possibility. A Shoal-based compute grid is another possibility with relatively small incremental code to be written to make that happen. I can also think of a Derby cluster using Shoal as the underlying clustering and replication mechanism. Once you think of Derby, any other product could be applied here. For instance, a directory server cluster, a web server cluster, a message queue cluster, etc. Another possibility is that Web-only apps could directly use Shoal to cache states among instances of web containers. So you see, the possibilities are endless and is only limited by imagination. :)


Does the shoal is capable to handle httpsession/SSFB failover on Java EE applications deployed on glassfish ? I know that it is not stable now, but I want to known if those failover will be possible for glassfish FCS. Thanks.

Posted by Claudio Miranda on February 27, 2007 at 10:56 PM PST #

I`m using Shoal (v1.1) in production. It`s an excellent project.

Posted by Alexandre on January 02, 2009 at 05:06 AM PST #

Hi Alexandre
Thanks for your feedback. Its very good to hear that you use 1.1 in production.

Would you be willing to share your success story with us so we can feature it in our Stories blog (

Posted by Shreedhar Ganapathy on January 04, 2009 at 10:19 AM PST #

Dear Shreedhar,

I`m a system architect and I develop solutions for telecommunications market. My recent successful project is an application that is used as integration middleware between a voice platform (of a big telecom company in Brazil – Embratel) and brazilian government database.

The requirements of that middleware is to be fault tolerant, to be high available and have high performance (the high performance was obtained by using another great project from ASF – the Apache Mina). I think that Shoal has a great design and the API is very elegant and clean. There are 4 servers running, in active-backup mode (two active and two in standby). If the active server fails (the active server is the leader), the second one must be active in less than 2 seconds. I configured Shoal`s heartbeat to 500 ms with tolerance to 3 heartbeat misses. I`ve tested the application, killing the instance, shutting down the server machine and removing the network cable. In all the cases Shoal works fine, choosing another leader automatically.

So, every Brazilian person who make a call to a free government phone, will be using my application that was build using the full Shoal capabilities! Congratulations for the excellent job.

Alexandre Verri - from Brazil

Posted by Alexandre Verri on January 06, 2009 at 03:44 AM PST #

Hi Alexandre
This is excellent news! If you need any time critical support for Shoal, please contact me so I can arrange an exceptional support plan from Sun as currently we don't yet offer separate time critical support for Shoal.
I am very glad to know of this success story.

I will send you our stories blog questionnaire so that we can feature it in the blog?



Posted by Shreedhar Ganapathy on January 06, 2009 at 04:19 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed

Shreedhar Ganapathy


« December 2016