For testing purposes, the
lighttpd.conf
configuration file shown in Listing 7 is
sufficient to launch a load balancer on
port 1981 to our three instances.
The configuration file is relatively
self-explanatory. The hash load balancing strategy dispatches requests of a
given client to the same instance for as
long as the instance remains running.
When Lighttpd detects that an instance
cannot be reached while trying to dispatch a request, Lighttpd automatically
selects another instance, inducing a
session failover.
Based on the configuration file above,
we can launch Lighttpd as a load balancer using the following command:
$ lighttpd -D -f lighttpd.conf
2011-07-01 15:23:59: (log.c.166)
server started
Failover in Action
We can connect to the application on
port 1981 and reach the application,
as illustrated in Figure 2. We see that
some instance successfully handled
our request.
Using a Web inspector found in
popular Web browsers, we can get a
hint regarding which instance was first
assigned to us by the load balancer. The
cookie value JREPLICA contains the name
of the instance, which is instance2 in the
example shown in Figure 2.
We can put the failover mechanism
in action by shutting down instance2 and
reloading the page or by performing an
action, such as adding or deleting a task.
Another of the two remaining instances
processes the request without any loss
of session information. You can further
try the mechanism by starting and stop-
ping instances at will to see the effects.
Troubleshooting note: You might
encounter certain problems with ses-
sions not working as they should in the
case of failover on an instance running
on a different host than the previous
one. This is most likely due to your
particular combination of network, load
balancer, and GlassFish server
settings causing cookies to be
issued for different domains. It
is possible to explicitly instruct
a GlassFish server to define the
cookie domain value that you
expect based on the HTTP load
balancer public URL. To do that,
you need to add a WEB-INF/
glassfish-web.xml file in your
Web applications with content
similar to the code shown in
Listing 8 for connections to
http://my.wonderfulapp.com/.
server.document-root = "."
server.port = 1981
server.modules += ( "mod_proxy" )
proxy.balance = "hash"
proxy.server = ( "" =>
(
(
"host" => "127.0.0.1",
"port" => 28080
),
(
"host" => "127.0.0.1",
"port" => 28081
),
(
"host" => "192.168.56.101",
"port" => 28080
)
)
)
COMMUNITY
JAVA IN ACTION
Download all listings in this issue as text
Conclusion
This article concludes the GlassFish
clustering series. The first article focused
on the centralized provisioning and
management of a cluster; this one dealt
with enabling high-availability support
for applications and session failover.
We also discussed the options for
setting up a front-end HTTP load balancer for a GlassFish cluster, choosing
a less-documented yet easy-to-test
option without loss of generality. While
we did not illustrate stateful EJB session
replication in our examples, all points
remain valid.
GlassFish is not just a convenient
server in development contexts; it is
also a full-fledged server for produc-
tion when horizontal scaling is required
both for performance and high-
availability purposes. It provides an
elegant and easy-to-grasp tool for cen-
trally provisioning and administering
cluster instances. </article>
ABOUT US
LEARN MORE
•;“GlassFish Server Load Balancing Plug-in
Installation and Setup”
•;Beginning;Java;EE;6;with;GlassFish;3 by
Antonio Goncalves (Apress, 2010)
•;The;Java;EE;6;Tutorial:;Basic;Concepts,
fourth edition (Prentice Hall, 2010)
