In the previous part (link) I get you running with a simple Glassfish 3.1 cluster setup with 2 instances running on 2 nodes. Now we have a cluster setup and can deploy an application one time and it will run on both nodes, no big deal, it doesn’t get us anywhere. So in part 2 we will do some modifications to our virtualbox server setup and create a web application with sessions replicated to both instances.
- The server and cluster setup from part 1 (link)
Preparation of host and Virtualbox guests:
In part 1 we used n1 and n2 as hostname, this creates trouble for this part. A key information for the sessions is the server-hostname (domain) and we cannot share sessions between totally different hosts.
- Update guest server hostname
Change etc/hosts and /etc/hostname
Server n1 becomes n1.test.com
127.0.0.1 localhost 127.0.1.1 n1.test.com 127.0.0.1 n1.test.com 192.168.56.102 n2.test.com
Server n2 becomes n2.test.com
127.0.0.1 localhost 127.0.1.1 n2.test.com 127.0.0.1 n2.test.com 192.168.56.101 n1.test.com
- You can use any domain name (other than test.com, which I dont own btw).
- The IP addresses must fit your own Virtualbox setup.
- Update your host
The host running Virtualbox. Change /etc/hosts
192.168.56.101 n1.test.com 192.168.56.102 n2.test.com
- Check multicast
The communication between the nodes is using multicast for the session replication. The Glassfish team gives us a tool to verify if your servers can “see” each other.
Go to the bin folder of the Glassfish installation and execute ./asadmin validate-multicast on both nodes
You should get feedback like this
Preparation of Glassfish Cluster
We need to update the node information for former n2 server.
- Modify node configuration (point to new hostname)
Create a simple web application with Netbeans
We will create a simple JSP app that displays the session id and some extra information.
- Create Web Application WebSessionDemo
- Update the index.jsp page
Netbeans creates the default page, which we need to update a bit to display the session information
<%@page import="java.text.SimpleDateFormat"%> <%@page import="java.text.DateFormat"%> <%@page contentType="text/html" pageEncoding="UTF-8"%> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <title>WEB Session Demo</title> </head> <body> <h1>Session Details:</h1> <% HttpSession httpSession = request.getSession(); out.println("Session ID: " + httpSession.getId()+ "<br />"); DateFormat formatter = new SimpleDateFormat("dd/MM/yyyy hh:mm:ss.SSS"); String created = formatter.format(httpSession.getCreationTime()); out.println("Session created: " + created + "<br />"); String lastAccess = formatter.format(httpSession.getLastAccessedTime()); out.println("Session last access: " + lastAccess + "<br />"); out.println("Server Request: " + request.getServerName() + "<br />"); out.println("Server Instance executing: " + System.getProperty("com.sun.aas.instanceName") + "(" + java.net.InetAddress.getLocalHost().getHostName() + ")" +"<br />"); %> </body> </html>
- Lets deploy this app (like the application in the part 1) and see what happens..
- No change, we have one application deployed into 1 cluster running in 2 instances. Each one maintains its own session.
Changes to the application
We need to make a few configuration changes to the application in order to support the session replication we look for.
- Add a web.xml
By default it is no longer around for Java EE6
- Change web.xml
Tick the distributable option (or add <distributable/> to the xml file)
- Change sun-web.xml
Add session config section with domain setting
<session-config> <cookie-properties> <property name="cookieDomain" value="test.com"/> </cookie-properties> </session-config> root@ubuntu:/disk2#
Remark: This will allow Glassfish to share the same cookie for ALL subdomains under test.com, even the cookie in our test contains only the session-id. There might be certain risk in doing so. Check your policies and security requirements.
- Clean and Build
- Deploy the application
Use the availability option !
We have the same session replicated from instance 1 on node 1 replicated to instance 2 on node 2. That is the most simple HA setup, on of the nodes could go offline (try by switching off one of the virtualbox guests) and the other one is still alive (and so is our session).
The next improvement would be to use load-balancing, so the user will open only 1 domain and the cluster setup will quietly do all the magic in the background.
In the next part I will look into resources in the cluster context. Stay tuned.