GlassFish 4: Features for High Availability

 

The main objective of a highly available system is tominimize downtime. As a brand new major release, and the only Java EE 7 application server currently available, does GlassFish 4.0 provide you with what you need from a reliable server?
Clustering

 

 

Glassfish 4.0, as an open source release, provides early access to clustering features, with a fully tested feature set available from version 4.1, so clustering should not be seen as a supported feature in version 4.0. In reality, this makes little difference, since the open source release isn’t supported by Oracle anyway! The good news is that version 4.0 (including clustering) is fully supported by C2B2!
In practical terms, setting up a GlassFish 4 cluster isconfigured thesame way as in version 3.1.2. GlassFish follows the same model forclustering as many other application servers, so the key concepts should befamiliar to a lot of people.

The Domain Admin Server (DAS) manages the clusterand provides a graphical admin console to create configure server instances.Physical machines are called Nodes and the DAS is, as you might guess, on theAdministration Node, which can also host other cluster instances. GlassFish clustersscale up by adding more instances to nodes and out by adding more nodes.

Session Replication

If the objective for a highly available system is to accept that unplanned failures and downtime happen and mitigate the impact, then part of that impact is the loss of session data for your customers.

Since, as I’ve mentioned, clustering in 4.0 is officially only an early access feature, the alternative to native session data management is to store your sessions in a distributed cache, like Ehcache or Memcached.

Taking advantage of the high availability features of a distributed cache means that you no longer have to worry about managing your session data, since it’s always available in the cache.

Early access feature or not, GlassFish 4 clusters still provide session persistence through failover of distributed HTTP session data and stateful session bean data.

This failover is accomplished by in-memory session replication with clustered server instances, so if you are using session persistence with a load balancer, you'll need to enable sticky sessions (session affinity) to make sure no data is lost or sent to the wrong server. One such load balancer that can be configured like this is the GlassFish Loadbalancer plug-in...

 

 

Load Balancing

GlassFish's Loadbalancer plug-in is a separate ZIP distribution to be installed after the server has been installed and configured with your chosen web server. It's compatible with the Oracle iPlanet Web Server, Oracle HTTP Server (OHS), Apache HTTP Server, and Microsoft Internet Information Server (IIS), but it is only available for Oracle GlassFish customers - open source users will have to look elsewhere!
 
Fortunately, as in previous releases, Glassfish 4 supports the AJP protocol, so configuration isas easy as ticking the box to enable the JK listener on any new or existingHTTP listener.
 

Your web server can then be configured to forward AJP requests, commonly with Apache and mod_proxy, which is bundled with the web server, or mod_jk.

 

So, is GlassFish 4.0 Ready for Prime Time?

That is, quite literally in some cases, the million dollar question. As with any part of your middleware stack, the features and benefits you get out of it is directly proportional to the time you invest in understanding it and making it work for you.
 
Can you use GlassFish 4.0 as the foundation for a highly available infrastructure? Without a doubt - providing your risk analysis is comprehensive and your failure plans are fully tested regularly!