of a cluster. To do that, it relies on the
Shoal group management service (GMS)
that all instances refer to. This service
is based on multicast User Datagram
Protocol (UDP) socket communications
for one-to-many communications and
the Grizzly project for point-to-point
communications. This service provides
efficient propagation of state change
events. It also absorbs instances of
volatility in a group, and it provides the
support for failover and recovery when
instances leave. The GMS uses a
consistent hash-based algorithm
whereby instances know which instance
hosts a replica of some state. This
reduces the network multicast broadcast
traffic. A simpler approach would be for
an instance to broadcast a lookup to all
instances in a group, as was the case in
earlier versions of GlassFish.
To briefly illustrate how high avail-
ability works in GlassFish, let’s consider
the case of HTTP sessions. A session is
obtained on the server side through the
use of a cookie that is carried along with
each request and response. Requests are
always processed by the same instance
for performance rea-
sons (we will see later
how to do that). Objects
stored in an HTTP
session are retrieved
through the value of the
cookie (JSESSIONID, in
the case of GlassFish),
which acts as a key. If
the instance disappears,
failover happens by
processing the requests
with another active instance in the clus-
ter. Provided that cookies are properly
managed by the front-end server and the
cookie domain policies are correct, the
new instance can access the same HTTP
session data because it is available either
locally in cache or from another instance.
@Named
@SessionScoped
public class TaskList implements Serializable {
private List<String> tasks = new ArrayList<String>() {
{
add("Wash the dishes");
add("Invent the next JVM language");
add("Get a better salary");
}
};
JAVA IN ACTION
public List<String> get Tasks() {
return unmodifiableList(tasks);
}
public void add(String task) {
tasks.add(task);
ABOUT US
Download all listings in this issue as text
is no further requirement from the
application code point of view.
Making a Java
EE application
ready for high
availability
is mostly an
infrastructure
duty.
Getting the Cluster Ready for
High Availability
There are further useful commands
when dealing with a cluster. The command shown in Listing 3 checks the
health of a cluster by giving us useful
information about the running and
stopped instances.
Instances must be on the same net-
work subsystem for state replication to
work, because part of the communica-
tions are made using UDP multicast
sockets. We can check that this require-
ment is satisfied by using the command
shown in Listing 4.
