• Windows 7 
• GlassFish 4.0
• Java EE 7 32 bit 
• JDK 1.7.0_45 32 bit 
• NetBeans 7.4

• Go to http://www.oracle.com/technetwork/java/javaee/downloads/index.html
• To download the SDK, JDK, and GlassFish, click on the download link for Java EE 7 SDK with JDK 7 U45 and select Windows(not Windows x64, this guide is using 32 bit Java).
•  Install to the default location like any other regular program
• If you decide to install in a different location, you will have to alter any explicit file paths in the guide to correspond to your own installation location.

• Go to https://NetBeans.org/downloads/index.html
• Click on the Downloadbutton for Java EE
•  You may note that this also comes bundled with GlassFish 4.0. Handy, but redundant at this stage if you’ve followed this guide.
• Install like any other program, to the default location
• You can configure it not to reinstall GlassFish, or simply leave it as default; reinstalling GlassFish with NetBeans has the positive outcome of NetBeans auto-configuring a default GlassFish Server for you to deploy the web app to, though it does default to a different install location, potentially letting you install GlassFish twice.

•  Click on Start, and then right click on Computer and select Properties
•  Select Advanced System Settings from the list on the left of the window.
•  Click on Environment Variables
• Select the Pathvariable under System Variables, and click on Edit
•  Add the path for the JDK bin – on a default installation that is: C:\Program Files (x86)\Java\jdk 1.7.0_45\bin
• Ensure there is a semi colon separating out the extra path directory from the previous directory

• Click Newunder System Variables
•  Enter JAVA_HOMEas the variable name
• Enter the file path of the JDK – on a default installation that is: C:\Program Files (x86)\Java\jdk 1.7.0_45

• Select Tools, then Servers from the NetBeans toolbar.
• Select Add Server, on the bottom left of the pop up window.
• Select GlassFish Server, and press Next.
• You can leave the Name as the default “GlassFish Server”.
• Browse to where GlassFish is installed and accept the license agreement before clicking Next.
• If you let the Java installer install GlassFish, you should find it at: C:\glassfish4
• Leave the domain location at “Register Local Domain”, and the Domain Name as “domain1”.
• Enter “admin” as the user name, and a password if you want, before finally clicking Finish.
• Note – If you let NetBeans set up the server, then when you first start up the server it will set a random String as the password with a username of admin. NetBeans won’t leave you in the dark though, it will auto fill in the password for you when it asks for it.
• If you want to look at the username or password, you can find them by clicking Tools, then Servers, and selecting the server from the list.

• Click on Start, and then right click on Computer and select Properties
• Select Advanced System Settings from the list on the left of the window.
•  Click on Environment Variables
• Select the Pathvariable under System Variables, and click on Edit
• Enter the file path of the GlassFish bin folder
• NetBeans Install: C:\Program Files (x86)\glassfish-4.0\bin
• Java Install: C:\glassfish4\bin
• Enter the file path of the GlassFish server
• NetBeans Install: C:\Program Files (x86)\glassfish-4.0\glassfish
• Java Install: C:\glassfish4\glassfish

• Right click on the project, SimpleWebApp, hover over New to expand the list, and select JavaClass.
• Enter Person as the class name, and enter org.mypackage.models as the package.
• Click Finish to create the class.

 public class Person implements Serializable  

• Declare private variables of the following:
• A String called name– This will be used to store the name of the user
• A byte called age– This will be used to store the age of the user once it has been calculated. Unless filling in an obscure date of birth, a person is not realistically going to be over 127 years old, so only a byte is needed.
• A String called dateOfBirth– This will be the String representation of the user given date of birth.
• A Calendar called birthday– This will be the Calendar representation of the user’s date of birth, a more workable format for a date of birth.
• A DateFormat called birthdateFormat– The accepted format of the user’s date of birth.
• A Date called birthdate– This is the date of birth in a Date Format, used for converting the date of birth from a String to a Calendar.
• A Calendar called todaysDate– Stores today’s date, used for calculating the age of the user.

• Create a constructor with no arguments, initialising the variables as:

 name = "";  
 age = 0;       
 birthday = GregorianCalendar.getInstance();  
 birthdateFormat = new SimpleDateFormat("yyyy-MM-dd");  
 dateOfBirth = birthdateFormat.format(new Date());  
 birthdate = new Date();  
 todaysDate = GregorianCalendar.getInstance();  

• Right click on the name variable in the Source Editor in the bottom left of NetBeans, expand the Refactor list, and click on Encapsulate Fields. This window displays the variables in the class that can be encapsulated, providing the means to generate Getter and Setter methods for variables, and to automatically set the visibility of said variables, Getter, and Setter methods. We can leave the default settings, but with two additions:
• Create a Getterfor age– We don’t need a Setter as this is calculated inside the class, not set by an external controller.
• Create a Setterfor dateOfBirth– We don’t need a Getter within the scope of this tutorial, as we don’t have any pages that will access this attribute.

• Click Refactor to generate the code. Were our variables not already declared as private, the selection of private for the Field Visibility would have declared them as such for us. This will also have added JavaDoc annotations, metadata, for the Getter and Setter methods. 

 package org.mypackage.models;  

 import java.io.Serializable;  
 import java.text.DateFormat;  
 import java.text.SimpleDateFormat;  
 import java.util.Calendar;  
 import java.util.Date;  
 import java.util.GregorianCalendar;  


 public class Person implements Serializable  
 {  
     private String name;  // The name of the user  
     private byte age;  // The age of the user  
     private String dateOfBirth; // The date of birth of the user  
     private Calendar birthday; // The birthday of the user  
     private DateFormat birthdateFormat; // The format of the birth date  
     private Date birthdate; // The dateOfBirth in a Date format  
     private Calendar todaysDate;  // Todays date  

     // Initialise any variables with default values  
     public Person()  
     {  
         name = "";  
         age = 0;       
         birthday = GregorianCalendar.getInstance();  
         birthdateFormat = new SimpleDateFormat("yyyy-MM-dd");  
         dateOfBirth = birthdateFormat.format(new Date());  
         birthdate = new Date();  
         todaysDate = GregorianCalendar.getInstance();  
     }  

     // The Getter method for the name  
     public String getName()   
     {  
         return name;  
     }  

     // The Setter method for the name  
     public void setName(String name)   
     {  
         this.name = name;  
     }  

     // The Getter method for the age  
     public int getAge()   
     {          
         return age;  
     }  

     // The Setter method for the date of birth  
     public void setDateOfBirth(String dateOfBirth)   
     {  
         this.dateOfBirth = dateOfBirth;  
     }  
 } 

• Create a private void method calculateAge().

• Create a try clause – as we are parsing from a String to a Date, we need to catch a Parse Exception if one is thrown.

• Within the try clause:

• Parse the dateOfBirth String in the format of birthdateFormat, and set this as birthdate

 birthdate = birthdateFormat.parse(dateOfBirth);  

• Use the setTime method of Calendar to set the birthday variable as the formatted Date value of birthdate

 birthday.setTime(birthdate);  

• End the try clause and catch the exception with a basic message (bad practice as exceptions should not just be ignored like this, but for this demo we can get away with it).

 catch (ParseException ex)   
 {  
   System.out.println("Parse Exception when parsing the dateOfBirth");  
 }  

• Subtract the year of the user’s date of birth from today’s year to get the difference in years, before then casting it as a byte. Set the age variable as this value.

 age = (byte)(todaysDate.get(Calendar.YEAR) - birthday.get(Calendar.YEAR));  

• Add the agevariable, currently representing the difference in years, to the user’s date of birth, the birthday variable, to get the user’s birthday for this year.

 birthday.add(Calendar.YEAR, age);  

• Compare today’s date against the user’s birthday this year, using the todaysDate and birthday variables respectively, to see if today’s date is before the user’s birthday, decrementing age if it is.

 if (todaysDate.before(birthday))  
 {  
age --;  
 }  

The method should now look like this:

private void calculateAge()  
{  
       try   
       {  
          // Convert the user supplied date of birth String to a Date in the specified format  
          birthdate = birthdateFormat.parse(dateOfBirth);  

          // Cast the Date value to a Calendar to allow easier use  
          birthday.setTime(birthdate);  
       } 

       catch (ParseException ex)   
       {  
System.out.println("Parse Exception when parsing the dateOfBirth");  
       }  

       // Calculate the age  
       age = (byte)(todaysDate.get(Calendar.YEAR) - birthday.get(Calendar.YEAR));  

       // Get the date of the user's birthday this year  
       birthday.add(Calendar.YEAR, age);  

       // Check if the user's birthday has passed this year  
       if (todaysDate.before(birthday))  
       {  
          // Reduce the age by one if it hasn't  
          age --;  
       }  
}  

• Add in the method call for calculateAge before the returnstatement in the getAge() method.

 calculateAge();  

 package org.mypackage.models;  

 import java.io.Serializable;  
 import java.text.DateFormat;  
 import java.text.ParseException;  
 import java.text.SimpleDateFormat;  
 import java.util.Calendar;  
 import java.util.Date;  
 import java.util.GregorianCalendar;  


 public class Person implements Serializable  
 {  
     private String name;  // The name of the user  
     private byte age;  // The age of the user  
     private String dateOfBirth; // The date of birth of the user  
     private Calendar birthday; // The birthday of the user  
     private DateFormat birthdateFormat; // The format of the birth date  
     private Date birthdate; // The dateOfBirth in a Date format  
     private Calendar todaysDate;  // Todays date  

     // Initialise any variables with default values  
     public Person()  
     {  
         name = "";  
         age = 0;       
         birthday = GregorianCalendar.getInstance();  
         birthdateFormat = new SimpleDateFormat("yyyy-MM-dd");  
         dateOfBirth = birthdateFormat.format(new Date());  
         birthdate = new Date();  
         todaysDate = GregorianCalendar.getInstance();  
     }  

     // The Getter method for the name  
     public String getName()   
     {  
         return name;  
     }  

     // The Setter method for the name  
     public void setName(String name)   
     {  
         this.name = name;  
     }  

     // The Getter method for the age  
     public int getAge()   
     {      
         // Call the method to calculate the age before returning it  
         calculateAge();  

         return age;  
     }  

     // The Setter method for the date of birth  
     public void setDateOfBirth(String dateOfBirth)   
     {  
         this.dateOfBirth = dateOfBirth;  
     }  

     // The method that calculates the user's age from their date of birth  
     private void calculateAge()  
     {   
         try   
         {  
            // Convert the user supplied date of birth String to a Date in the specified format  
            birthdate = birthdateFormat.parse(dateOfBirth);  

            // Cast the Date value to a Calendar to allow easier use  
            birthday.setTime(birthdate);  
         }

         catch (ParseException ex)   
         {  
            System.out.println("Parse Exception when parsing the dateOfBirth");  
         }  

         // Calculate the age  
         age = (byte)(todaysDate.get(Calendar.YEAR) - birthday.get(Calendar.YEAR));  

         // Get the date of the user's birthday this year  
         birthday.add(Calendar.YEAR, age);  

         // Check if the user's birthday has passed this year  
         if (todaysDate.before(birthday))  
         {  
            // Reduce the age by one if it hasn't  
            age --;  
         }  
     }  
 }  

• Right click on the Project in the Projects pane, expand the New list, and select Servlet.
• Provide a Class Name of PersonServlet, a Package of org.mypackage.controllers, and click Next
• Check the box to Add information to deployment descriptor to generate the XML code providing the means of accessing the servlet from the indexpage.

• Declare the private variables for the servlet to take in from the index page, name and dateOfBirth.
• Declare and initialise the private variable to be used to identify what will be our Person object when passed to another page, personID.

 private String name;  // The user's name  
 private String dateOfBirth; // The user's date of birth  
 private String personID = "personBean";  // The ID of the Person object  

• Initialise the name and dateOfBirth variables as the parameters of the same name from the HTTP request, with the getParameter method (be sure to put the parameters between ""!).

 name = request.getParameter("name");  
 dateOfBirth = request.getParameter("dateOfBirth");  

import org.mypackage.models.Person; 

Person person = new Person();  

• With the Person object initialised, utilise its Setter methods to update the name and dateOfBirth attributes with those supplied by the user.

 person.setName(name);  
 person.setDateOfBirth(dateOfBirth);  

• Set personID and person as attributes of the request.

 request.setAttribute(personID, person);  

• Pass control to what will be our responding page, userAgeResponse.jsp, and forward the request and response parameters to it.

 RequestDispatcher dispatcher = getServletContext().getRequestDispatcher("/userAgeResponse.jsp");  
 dispatcher.forward(request, response);  

 package org.mypackage.controllers; 

 import java.io.IOException; 
 import javax.servlet.RequestDispatcher; 
 import javax.servlet.ServletException; 
 import javax.servlet.annotation.WebServlet; 
 import javax.servlet.http.HttpServlet; 
 import javax.servlet.http.HttpServletRequest; 
 import javax.servlet.http.HttpServletResponse;
 import org.mypackage.models.Person 

 // Specify the name of the servlet and the URL for it 
 @WebServlet(name = "PersonServlet", urlPatterns = {"/PersonServlet"}) 
 public class PersonServlet extends HttpServlet { 

     private String name;  // The user's name 
     private String dateOfBirth; // The user's date of birth 
     private String personID = "personBean";  // The ID of the Person object 

     /** 
      * Processes requests for both HTTP <code>GET</code> and <code>POST</code> 
      * methods. 
      * 
      * @param request servlet request 
      * @param response servlet response 
      * @throws ServletException if a servlet-specific error occurs 
      * @throws IOException if an I/O error occurs 
      */ 
     protected void processRequest(HttpServletRequest request, HttpServletResponse response) 
          throws ServletException, IOException  
     { 
         // Retrieve the user input values from the Welcome Page 
         name = request.getParameter("name"); 
         dateOfBirth = request.getParameter("dateOfBirth"); 

         // Initialise a new Person object 
         Person person = new Person(); 

         // Update the default values in the Person object with the user supplied values 
         person.setName(name); 
         person.setDateOfBirth(dateOfBirth); 

         // Set the person object and its identifier as attributes of the request 
         request.setAttribute(personID, person); 

         // Load the userAgeResponse Page 
         RequestDispatcher dispatcher = getServletContext().getRequestDispatcher("/userAgeResponse.jsp"); 
         dispatcher.forward(request, response); 
     }

  // … Default HttpServlet methods … 

 } 

• Right click the SimpleWebApp node in the Projects window, expand the New list, and click on JSP, short for JavaServer Page.
• Name the JSP userAgeResponse, leave the other settings as default, and click Finish.

• Open the palette by clicking on Window from the NetBeans toolbar, expand the IDE Tools list, and select Palette
• This can also be done with the keyboard shortcut Ctrl + Shift + 8

• Expand the JSP tab, and drag a Use Bean into the editor above the HTML tags of the page. A window will appear, enter personBean as the ID, org.mypackage.models.Person as the Class, and set the Scope to request. This will be used to access, as you may be able to tell from the parameters, the Person class, and the Get and Set methods within it. It will in particular be accessing the person object we created and sent to the page from our servlet, utilising the ID of personBean, which was the value of personID passed to it from the servlet.

<jsp:useBean id="personBean" scope="request" class="org.mypackage.models.Person" />  

• Drag two Get Bean Propertys between the bodytags with the Bean Name for both set to personBean, and the Property Name set as name for one, and age for the other. This calls the Getter method, for the nameand age attributes respectively, from the class of the object with the ID specified in the Use Bean, person.  

<jsp:getProperty name="personBean" property="name" />  
<jsp:getProperty name="personBean" property="age" />  

• Add some friendly text and a line break between the two Get Bean Properties for ease of reading to finish off the page.

 Hello <jsp:getProperty name="personBean" property="name" />!  

<br>  

 You are <jsp:getProperty name="personBean" property="age" /> years old!  

<%@page contentType="text/html" pageEncoding="UTF-8"%>  
<!DOCTYPE html>  

<!--  
 Gain access to the person object  
 -->  
<jsp:useBean id="personBean" scope="request" class="org.mypackage.models.Person" />  

<html>  
<head>  
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">  
<title>Your Age</title>  
</head>  
<body>  

<!--  
      Pull the name and age of the user from the Person object 
      -->  
      Hello <jsp:getProperty name="personBean" property="name" />!  

<br>  

      You are <jsp:getProperty name="personBean" property="age" /> years old!  

</body>  
</html>  

• Open up the Palette if it isn’t already open, and expand the HTML Forms menu. Remove any default text inside of the body of the code, before pulling a Form into the body from the Palette. Set our servlet, PersonServlet, as the Action, GET as the Method, and give it a Name of inputForm. This specifies that the inputs from this form will be sent to our servlet via the HTTP GET method.

<form name=“Input Form” action=“PersonServlet”>  

• Make some space between the form tags, and place a Text Input item inside. Give the input a Name of name, and hit OK, leaving the other fields as default. The Name field in this instance is giving the variable name to be passed, so is the same name parameter extracted from the HTTPServletRequestrequestin our servlet.

<input type=“text” name=“name” value=“” />  

• Create another Text Input with the name of dateOfBirthto satisfy this foresight of ours. Once generated, alter the type from text to date, providing some input validation, and provide it a default date value of the format yyyy-mm-dd to give the user a visual cue of the input format if the browser does not support providing automatic formatting for the HTML date tag. 

<input type=“date” name=“dateOfBirth” value=“2014-01-29” />  

• Type in some descriptive text before the text inputs to give the input fields a label for the user to see, and place a line break between the fields to improve readability.

 Enter Your Name: <input type="text" name="name" value="" />  

<br>  

 Enter Your Date of Birth: <input type="date" name="dateOfBirth" value="2014-01-29" />  

• Finally, place another line break after the text inputs and drag a Button in, giving it a Label of Submit, leaving the Typeas Submit, and a Name of submitButton.

<input type=”submit” value=”OK” />  

<!DOCTYPE html>  
<html>  
<head>  
<title>Welcome Page</title>  
<meta charset="UTF-8">  
<meta name="viewport" content="width=device-width">  
</head>  
<body>  

<!--   
       Create an input form to take in the user's name and date of birth  
       and send them to the servlet  
       -->  
<form name="Input Form" action="PersonServlet">  

<!--  
         Provide a label for the user to read and input fields,  
         passing on the name and date of birth  
         -->  
         Enter Your Name: <input type="text"
                      name="name"
                      value="" />  

<br>  

         Enter Your Date of Birth: <input type="date"
                           name="dateOfBirth"
                           value="2014-01-29" />  

<br>  

<!--  
         Provide a button as a means of submitting the user's data  
         -->  
<input type="submit" value="Submit" name="Submit Button"/>  

</form>  
</body>  
</html>  

• Right click on the project in the Projects pane, and click on deploy. This will start the GlassFish server, if it isn’t already running, undeploy any current version of the web app already deployed, and deploy the web app to the server.

• Click on the Run button, and the web app will now load in your browser.

• In NetBeans, right click on the project in the Projects window and click on Clean and Build.

• Enter the command asadmin start-domain. The asadmin command is a GlassFish utility that lets you run administrative tasks, such as starting and stopping servers. As we are using the default GlassFish server, domain1, we do not need to enter a domain name.
• Navigate to the dist folder containing the SimpleWebApp.war file.
• Alternatively you can type out the file path to SimpleWebApp.war each time it is used.
• Type the command asadmin deploySimpleWebApp.war.
• If the SimpleWebApp is already deployed, you can force a redeploy using the following command - asadmin deploy --force=true SimpleWebApp.war.
• Open your browser and navigate to http://localhost:8080/SimpleWebApp  

• excessive Garbage Collection
• high CPU usage
• a memory leak

• In the infinispan endpoint subsystem, we will configure hotrod client's to connect to the JDG server instance on socket 11222. 
• The name of the cache container to host each of the cache instances will be held in the container named "clusteredcache".
• We have configured the infinispan core subsystem to the default cache container named "clusteredcacahe" whereby we will allow for jmx statistics to be collected relating the configured cache entries i.e statistics="true"
• We have created a new distributed cache named "directory-dist-cache" whereby there will be two copies of each cache entry held on two of the 3 cluster nodes. 
• We have also set up an eviction policy whereby should there be more than 20 entries in our cache then cache entries will be removed using the LRU algorithm
• We should have configured nodes "server2" and "server3" to start up with a port offset of 100 and 200 respectively by configuring the socketing binding group element appropriately. Please view the socket bindings noted below.

......
<socket-binding name="hotrod" interface="management" port="11222"/>
......
/socket-binding-group>


To set the socket binding element with a port offset of 200 on "server3", we configure "clustered3.xml" with the following entry:

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:200}">

......
<socket-binding name="hotrod" interface="management" port="11222"/>
......
/socket-binding-group>

Before discussing the setup and configuration of our Hotrod client which will be used to interact with our JDG clustered HotRod server, we will start up each server instance to ensure our newly configured JDG distributed cache starts up correctly.

Open up 3 console Windows or Linux and execute the following start up commands:

Console 1:

1) Navigate to <JDG_HOME>\server1\jboss-datagrid-6.2.0-server\bin

2) Execute this command to start the first instance of our JDG cluster denoted "server1": clustered -c=clustered1.xml -Djboss.node.name=server1

Console 2:

1) Navigate to <JDG_HOME>\server2\jboss-datagrid-6.2.0-server\bin

2) Execute this command to start the second instance of our JDG cluster denoted "server2": clustered -c=clustered2.xml -Djboss.node.name=server2

Console 3:

1) Navigate to <JDG_HOME>\server3\jboss-datagrid-6.2.0-server\bin

2) Execute this command to start the third instance of our JDG cluster denoted "server3": clustered -c=clustered3.xml -Djboss.node.name=server3

Providing all 3 JDG instances have started up correctly, you should see output in the console window whereby we can see there are 3 JDG instances in the JGroups view:

HotRod Client Development Setup

Now that the Hotrod server is up and running, we now need to develop a Hotrod Java client which will interact with the clustered server application. The development environment consists of the following tools.

1) JDK Hotspot 1.7.0_45
2) IDE - Eclipse Kepler Build id:  20130919-0819

The HotRod client application is a simple application consisting of two Java classes. The application allows users to retrieve a reference to the distributed cache from the JDG server and then perform these actions:

a) add new cinema objects.
b) add and remove shows to each cinema object.
c) print the list of all cinemas and shows stored in our distributed cache.

The source code can be downloaded from github @ https://github.com/davewinters/JDG. We could use maven here to build and execute our application by configuring the maven settings.xml to point to the maven repository files we downloaded earlier and set up a maven project file (pom.xml) to build and execute the client application.

In this article we will build our application using the Eclipse IDE and run the client application on the command line. To create a HotRod client application and execute the sample application, one should complete the following steps:

1) Create a new Java Project in Eclipse
2) Create a new package named uk.co.c2b2.jdg.hotrod and import the source code that has been downloaded from Github mentioned previously.
3) Now we need to configure the build path in Eclipse to the appropriate JDG client jar files which are required to compile  application. You should include all the client jar files in the project build path. These jar files are contained in the JDG installation zip file. For example on my machine these jar files are located in the directory: <JDG_HOME>\server1\jboss-datagrid-6.2.0-server\client\hotrod\java
4. Providing the Eclipse build path has been configured appropriately, the application source should compile without issue.
5. We will need to execute the Hotrod application by opening the console window and executing the following command. Note the path specified here will differ depending on where the JDG client jar files and application class files are located in your environment:

java -classpath ".;C:\Users\David\Installs\jbossdatagrids62\server1\jboss-datagrid-6.2.0-server\client\hotrod\java\commons-pool-1.6-redhat-4.jar;C:\Users\David\Installs\jbossdatagrids62\server1\jboss-datagrid-6.2.0-server\client\hotrod\java\infinispan-client-hotrod-6.0.1.Final-redhat-2.jar;C:\Users\David\Installs\jbossdatagrids62\server1\jboss-datagrid-6.2.0-server\client\hotrod\java\infinispan-commons-6.0.1.Final-redhat-2.jar;C:\Users\David\Installs\jbossdatagrids62\server1\jboss-datagrid-6.2.0-server\client\hotrod\java\infinispan-query-dsl-6.0.1.Final-redhat-2.jar;C:\Users\David\Installs\jbossdatagrids62\server1\jboss-datagrid-6.2.0-server\client\hotrod\java\infinispan-remote-query-client-6.0.1.Final-redhat-2.jar;C:\Users\David\Installs\jbossdatagrids62\server1\jboss-datagrid-6.2.0-server\client\hotrod\java\jboss-logging-3.1.2.GA-redhat-1.jar;C:\Users\David\Installs\jbossdatagrids62\server1\jboss-datagrid-6.2.0-server\client\hotrod\java\jboss-marshalling-1.4.2.Final-redhat-2.jar;C:\Users\David\Installs\jbossdatagrids62\server1\jboss-datagrid-6.2.0-server\client\hotrod\java\jboss-marshalling-river-1.4.2.Final-redhat-2.jar;C:\Users\David\Installs\jbossdatagrids62\server1\jboss-datagrid-6.2.0-server\client\hotrod\java\protobuf-java-2.5.0.jar;C:\Users\David\Installs\jbossdatagrids62\server1\jboss-datagrid-6.2.0-server\client\hotrod\java\protostream-1.0.0.CR1-redhat-1.jar" uk/co/c2b2/jdg/hotrod/CinemaDirectory

6. The Hotrod client at runtime provides the end user with a number of different options to interact with the distributed cache as we can view from the console window below.

Client Application Principal API Details

We will not provide a detailed overview of the Hotrod application code however we will describe solely the principal API and code details briefly.

In order to interact with the distributed cache on the JDG cluster using the Hotrod protocol, we will use the RemoteCacheManager Object which will allow us to retrieve a remote reference to the distributed cache. We have initialised a Properties object with the list of JDG instances and the associated with HotRod server port on each instance. We can add Cinema objects into the distributed cache using the RemoteCache.put() method.

 private RemoteCacheManager cacheManager;
 private RemoteCache<String, Object> cache;

.....

Properties properties = new Properties();
 properties.setProperty(ConfigurationProperties.SERVER_LIST, "127.0.0.1:11222;127.0.0.1:11322;127.0.0.1:11422");
cacheManager = new RemoteCacheManager(properties);
cache = cacheManager.getCache("directory-dist-cache");
.....
cache.put(cinemaKey, cinemalist);

For further details on JDG please visit: http://www.redhat.com/products/jbossenterprisemiddleware/data-grid/

Webinar: Introduction to JBoss Data Grid -- Installation, Configuration and Development

 

• MBeans
• A server log
• Instrumentation (event) data

Note:

If you define a watch rule to monitor an MBean (or MBean attributes) that the Harvester is not configured to harvest, the watch will work. The Harvester will "implicitly" harvest values to satisfy the requirements set in the defined watch rules. However, data harvested in this way (that is, implicitly for a watch) will not be archived. See Chapter 7, "Configuring the Harvester for Metric Collection," for more information about the Harvester.

There are two ways to build rule expressions. Highlighted in red is a large text box which you will find is not editable. Clicking the “Edit” button will take you to a page where you can directly edit the rule as text. If you’re not familiar with WLDF query language rules, that might not seem like the most helpful feature but when you consider that it allows you to create a rule expression and copy the text for future reuse, the value becomes clear.

Highlighted in blue is the expression builder. Clicking “Add Expressions” will take you to a page where you can construct individual expressions. The most useful part of this feature is that it gives dropdown lists for the available attributes and operators:

The expression builder can also be used to arrange these expressions in a complex, but helpfully visual way, as shown below in an example server log watch:

Step 4: Configure an alarm

An alarm can be manually or automatically reset. If manually reset then the alarm will fire once and be disabled until there is manual intervention to reset it. Automatically resetting alarms will reset after a period of time (specified in seconds. This value will be the maximum frequency of the alarm triggering. For example, if an event happens regularly every 10 seconds and an alarm is configured to reset every 11 seconds, then we will get this scenario:

• The alarm is active and the event occurs, triggering and disabling the alarm.
• 10s later, the event happens again, but the alarm is still disabled.
• 1s later, the alarm is reset
• 9s later, the event happens again and this time, the alarm is not disabled, so triggers again.

This scenario is a little contrived, but it shows that setting the reset period to 11 seconds does not mean that the alarm will fire every 11 seconds, as in this case where it fired with a 20 second gap.

Step 5: Configure watch notifications

If you have already configured a notification, you can add it here. If not, just click save. We won’t cover notifications in this post, but they can always be added retrospectively to any watch.

 ####<26-Mar-2014 11:17:30 o'clock GMT> <Notice> <Diagnostics> <Mike-PC> <AdminServer> <[ACTIVE] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1395832650884> <BEA-320068> <Watch 'SocketsOpen' with severity 'Notice' on server 'AdminServer' has triggered at 26-Mar-2014 11:17:30 o'clock GMT. Notification details:   
 WatchRuleType: Harvester   
 WatchRule: ${com.bea:Name=AdminServer,Type=ServerRuntime//OpenSocketsCurrentCount} >=1   
 WatchData: com.bea:Name=AdminServer,Type=ServerRuntime//OpenSocketsCurrentCount = 2   
 WatchAlarmType: AutomaticReset   
 WatchAlarmResetPeriod: 10000   
>   
 ####<26-Mar-2014 11:17:39 o'clock GMT> <Error> <Socket> <Mike-PC> <AdminServer> <[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1395832659211> <BEA-000403> <IOException occurred on socket: Socket[addr=/127.0.0.1,port=58139,localport=7001]  
  java.net.SocketException: recv failed: Descriptor not a socket.  
 java.net.SocketException: recv failed: Descriptor not a socket  
      at jrockit.net.SocketNativeIO.readBytesPinned(Native Method)  
      at jrockit.net.SocketNativeIO.socketRead(SocketNativeIO.java:32)  
      at java.net.SocketInputStream.socketRead0(SocketInputStream.java)  
      at java.net.SocketInputStream.read(SocketInputStream.java:129)  
      at weblogic.socket.SocketMuxer.readFromSocket(SocketMuxer.java:980)  
      at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:922)  
      at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:888)  
      at weblogic.socket.JavaSocketMuxer.processSockets(JavaSocketMuxer.java:339)  
      at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:29)  
      at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)  
      at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)  
>   
 ####<26-Mar-2014 11:17:39 o'clock GMT> <Notice> <Diagnostics> <Mike-PC> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1395832659211> <BEA-320068> <Watch 'LogWatch' with severity 'Notice' on server 'AdminServer' has triggered at 26-Mar-2014 11:17:39 o'clock GMT. Notification details:   
 WatchRuleType: Log   
 WatchRule: (SEVERITY = 'Error')   
 WatchData: DATE = 26-Mar-2014 11:17:39 o'clock GMT SERVER = AdminServer MESSAGE = IOException occurred on socket: Socket[addr=/127.0.0.1,port=58139,localport=7001]  
  java.net.SocketException: recv failed: Descriptor not a socket.  
 java.net.SocketException: recv failed: Descriptor not a socket  
      at jrockit.net.SocketNativeIO.readBytesPinned(Native Method)  
      at jrockit.net.SocketNativeIO.socketRead(SocketNativeIO.java:32)  
      at java.net.SocketInputStream.socketRead0(SocketInputStream.java)  
      at java.net.SocketInputStream.read(SocketInputStream.java:129)  
      at weblogic.socket.SocketMuxer.readFromSocket(SocketMuxer.java:980)  
      at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:922)  
      at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:888)  
      at weblogic.socket.JavaSocketMuxer.processSockets(JavaSocketMuxer.java:339)  
      at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:29)  
      at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)  
      at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)  
  SUBSYSTEM = Socket USERID = <WLS Kernel> SEVERITY = Error THREAD = [ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)' MSGID = BEA-000403 MACHINE = Mike-PC TXID = CONTEXTID = TIMESTAMP = 1395832659211   
 WatchAlarmType: AutomaticReset   
 WatchAlarmResetPeriod: 5000   
>  

Mike Crofton

• server.xml - This is the main config file for Tomcat and contains the settings for most of the key Tomcat components.
• context.xml - This is a global config file used by all web apps running on Tomcat. If you wish to override the global settings you should create your own context.xml file and place it in the META-INF directory of your web app.
• web.xml - This is the global deployment descriptor used by all web apps running on Tomcat. If you wish to override the global settings you should create your own web.xml file and place it in the WEB-INF directory of your web app.
• tomcat-users.xml - This file contains details on users and their roles.

• Deploy new web apps
• List the currently deployed apps
• Start and stop your apps
• Reload an app
• Undeploy an app
• List the OS and JVM properties
• List JNDI resources

• From NetBeans, expand the Tools drop-down list from the toolbar, select Servers, and click on Add Server.
• From the new popup window, select GlassFish Server from the server type list, and give it a name, before clicking Next.
• You will be presented with the Server Location window, prompting you to enter the GlassFish installation location. For our newly built GlassFish server, this can be found at:
• install_dir/main/appserver/distributions/glassfish/target/stage/glassfish4 (where install_dir refers to the directory that main is located in)
• At the next window, leave the settings as their defaults.

• Load GlassFish (the main directory) into NetBeans.
• Open the Core Bootstrap Classes module: Modules, GlassFish Nucleus Parent Project, GlassFish Nucleus Core modules, Appserver Core Bootstraping Classes glassfish-jar. (The typo of Bootstraping is actually there at time of writing!). 
• Open up the MainHelper class for editing by double clicking on it from the Projects pane.

 if (minor < 7) { 

 if (minor < 12) { 

• From NetBeans, start the GlassFish Server in debug mode. 
• Click on the Debug drop-down from the toolbar, and select Attach Debugger.
• Use the JDPA debugger, with a SocketAttach Connector. The host will be the localhost(or the name of your machine), and the Port should be 9009 (the GlassFish default).
• Open the Window drop-down from the toolbar, expand the Debugging list, and click on Sources to open the Sources window.
• Right click in the Sources window, select Add Source Root, and add the main directory.

• Open the RestResponse class, found under GlassFish Appserver Parent Project, Admin Console Packages, Admin Console Common glassfish-jar (you may notice that the path to this module will be added to the Sources window).
• In the getResponseCode() method, add in the highlighted line before the large if statement, such that it looks like this (feel free to alter the message):

 ...
 String contentType = response.getHeaderString("Content-type");  
Logger.getLogger(RestResponse.class.getName()).log(Level.INFO, "Help me! The author keeps breaking me!");
 if (contentType != null) { 
 ... 

• Add in a break point on our newly added line.
• Save and then rebuild GlassFish with Maven.
• Restart GlassFish in debug mode and re-attach the NetBeans Debugger (you don't need to add the source root again).
• Open up a browser and navigate to the Admin Console.

Introduction

Application Overview

JConsole Overview

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443"/>

2) Database Pool Configuration:

<Resource name="jdbc/productdb" auth="Container" type="javax.sql.DataSource"
               maxTotal="10" maxIdle="30" maxWaitMillis="10000" logAbandoned="true"
               username="root" password="admin" driverClassName="com.mysql.jdbc.Driver"
               url="jdbc:mysql://localhost:3306/products"/>
</Context>

3) JVM Settings:

We have set the minimum and maximum heap size to 1GB respectively as below:

export CATALINA_OPTS="-Xms1024m -Xmx1024m"

Results

Although JMeter provides us with saome useful performance statistics, we will JConsole to monitor the performance of the test. We can observe below in Figure 2 and 3 that the maximum time to process a request out of 1878 requests processed by one of the Tomcat servers took 4858 milliseconds whereby it took 373041 milliseconds to process 1878 requests. In Figure 3, we can find out metrics for each of the AJP threads used to process requests. We have provided an example of just one here whereby it took just 73 milliseconds to process the last request whereby the maximum time to process any one request on this thread took 4744 milliseconds.

Figure 2: GlobalRequestProcessor Mbean Attribute Values

Figure 3: RequestProcessor Mbean Attribute Values

Scenario 3: Optimized Tomcat Instances

In this final test scenario, we will perform some basic tuning on both tomcat instances to the AJP connector configuration in server.xml, the connection pool configuration described in context.xml and the JVM heap size allocated to each Tomcat instance.

1) AJP Connector configuration:

The AJP connector configuration below is configured so that there are two threads allocated to accept new connections. This should be configured to the number of processors on the machine however two should be suffice here. We have also allocated 400 threads to process requests, the default value is 200. The "acceptCount" is set to 100 which denotes the maximum queue length to be used for incoming connections. The default value is 10. Lastly we have set the minimum threads to 20 so that there are always 20 threads running in the pool to service requests.

 <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" acceptorThreadCount="2" maxThreads="400" acceptCount="200" minSpareThreads="20"/>

2) Database Pool Configuration:

We have modified the maximum number of pooled connections to 200 so that there are ample connections in the pool to service requests.

<Context>
<Resource name="jdbc/productdb" auth="Container" type="javax.sql.DataSource"
               maxTotal="200" maxIdle="30" maxWaitMillis="10000" logAbandoned="true"
               username="xxxx" password="xxxx" driverClassName="com.mysql.jdbc.Driver"
               url="jdbc:mysql://localhost:3306/products"/>
</Context>

3) JVM Settings:

Since we have increased the maximum number of pooled connections and AJP connector thread thresholds above, we should increase the heap size appropriately. We have set the minimum and maximum heap size to 2GB respectively as below:

export CATALINA_OPTS="-Xms2048m -Xmx2048m"

Results

We can observe from the JConsole Mbean metrics below there is a significant improvement in performance. The maximum time it took to process a request is 2048 milliseconds and the overall processing time to handle 3464 requests is 206741 milliseconds. If we observe the result sin Figure 5 from an individual AJP thread, we can observe it took 46 milliseconds to process the last request whereby the maximum time it took to process a request on this thread is 1590 miliseconds. This particular thread has processed 141 requests whereby it took a total time of 5843 milliseconds to process these requests.

Figure 4: GlobalRequestProcessor Mbean Attribute Values

Figure 5: RequestProcessor Mbean Attribute Values

For more details on tomcat 8 connector parameters, please visit this link

JVM Heap Monitoring and Tuning

Code Instrumentation

In this blog, we will provide a brief overview of the new architecture of Hadoop 2, discuss how to set up a simple 3 node Hadoop 2 ( Hadoop 2.4) cluster on Amazon EC2 and demonstrate how to execute MapReduce jobs on the cluster. Finally, we will discuss how to monitor and perform basic diagnosis should issues occur while running MapReduce jobs. 

Hadoop 2 Overview

There have been a number of notable changes to the architecture of Hadoop from version 1 to version 2. In Hadoop v1, the job scheduler daemon which is responsible for resource management, job scheduling and monitoring is a major scalability bottleneck whereby an Hadoop cluster could only scale to approximately 4000 nodes before performance degradation issues occurred. Furthermore, the name node daemon represented a point of failure within the Hadoop cluster although one could use a secondary name node to store cluster-wide HDFS (Hadoop Distributed File System) metadata. Also, the Hadoop architecture was closely coupled to the MapReduce framework whereby this limited the possibility of running different distributed processing and machine learning frameworks on Hadoop. 

Hadoop v2 addresses these scalability, failover and integration concerns via YARN and HDFS federation. YARN (yet another resource negotiator) is responsible for cluster resource scheduling, job scheduling and  HDFS federation which allows for multiple namenodes/namespaces to be defined across the cluster to store and manage HDFS data in a cluster. The Node manager is a new process in the Hadoop 2 architecture which runs on nodes in the cluster to manage resourcing needs between the node it is deployed on and the resource manager.

• Instance Type: m3:large. There are multiple different image types depending on your application requirements but we chose a general purpose instance type for testing purposes. For more details on the different types navigate to http://aws.amazon.com/ec2/instance-types/. 
• We created a new key pair  to control access to the EC2 instances. You can modify the storage required by each instance however I used the default for this instance type.

Next Steps

In the next blog in this series, we will provide an overview and explore some of the API's available in the Apache Spark framework. Apache Spark is an in-memory distributed processing framework which provides very useful API's for processing streamed data, data residing on Hive and a machine learning framework to perform complex machine learning operations on large datasets. Apache Spark can also interoperate with data residing on HDFS.

Resources

1) http://hadoop.apache.org

2) http://hortonworks.com/blog/apache-hadoop-yarn-background-and-an-overview/

• SMTP Email
• JMS Message
• Diagnostic Image
• JMX Notification
• SNMP Trap

Which notification should I use?

There’s no right or wrong when it comes to choosing notification methods, but there is certainly annoying and non-annoying! Of the notification methods above, all but email are passive methods of alerting people concerned. The reason I classify them as passive is that you, as the end-user who wants to be notified, must perform some sort of action to consume that notification. For example, to consume JMS message data, you must use a JMS client and would likely process the data automatically, perhaps for graphing.

Email, in contrast, is an active method of alerting since the end user will be told when she gets a new email. The majority of smartphone equipped techy people will check their email because their phone has beeped at them, not because they were simply curious. If you find yourself staring out of a rainy window wondering at what treasures your inbox might hold, you likely have bigger problems than configuring WLDF.

So which is best: active or passive?

Well you want to be ahead of the curve with what’s happening in your environment, don’t you? So email it is! Decision made, then, off you go and configure WLDF to send emails for every time a watch is configured.

I’ll wait here.

Done?

How did that go down with your support team? Badly? I thought so.

The problem with just using a single notification method for every watch event is that you definitely want to be notified as soon as some critical event occurs that requires action, but what if the event is only medium or low priority, or can be recovered from automatically? In those cases, you absolutely don’t care about every single event and often you’d like a lot of data to be graphed for you to review at a later date, which email is certainly not built for.

As the signal to noise ratio goes down, you’ll find your support users increasingly set up rules to ignore alerts and you find yourself in the same position as before when something critical happens where no-one takes any notice because they’re ignoring all your usage results.

I’ll outline two different notification types here, though they are all straightforward to configure.

JMX Notification

To create your JMX notification, go to the diagnostic module where your watches are configured. In Configuration -> Watches and Notifications, click the “New” button in the Notifications tab in the lower pane. 

Next, there are just two steps. Select “JMX Notification” as the type, as shown in the image, then click Next to name your notification.

Enter a meaningful name in the name field and make sure the Enable Notification box is ticked. Click OK and your notification is created!

Email notification

In the same way as before, click the “New” button in the Notifications tab of the appropriate diagnostic module.

After selecting the type as SMTP email and giving it a meaningful name, click next to complete the final step

Choose the mail session you want to use, enter email addresses you want to alert with this notification and click finish.

If you haven’t already created a mail session, you can use the button here to make one without losing your place. This is a blog about WLDF not Java mail, so I won’t go into that, but they are simple enough to be described with a single page of documentation.

Using your notifications

Now you’ve created your notifications, you need to tell your watches to use them! In the screenshot below, I’ve opened my SocketsOpen watch from the last blog and moved across my JMX notification from “Available” to “Chosen”

That’s all there is to it! Obviously if you wanted to use the email notification, choose that instead or as well as the JMX notification.

It’s pretty obvious how the email notifications work – check your inbox. If you were to fire up JConsole to check your new MBean, however, you would find that you can’t access it. The reason for that is that you need to add the right WebLogic jar to the classpath before you start JConsole.

To demonstrate the JMX notification working, I used a single Java class that I stumbled across, and modified slightly, from an Oracle blog. Make sure to include weblogic.jar from the server/lib directory of your WebLogic installation in the classpath if running in the command line or the project build path as in my screenshot of Netbeans below:

What next?

Now you can create watches and notifications on WebLogic, you can configure a monitoring product like RHQ or Hyperic to monitor anything that you can configure a watch on; with JMX tools, this normally stops with MBeans, but thanks to watches you can also monitor server logs and instrument your applications!

Mike Crofton

Overview

Software Prerequisites

Test Topology

Figure 1

 TLSCertificateFile ./secure/certs/ldapserver.pem  
 TLSCertificateKeyFile ./secure/certs/ldapserver.pem  
 TLSCACertificateFile ./secure/certs/ldapserver.pem  

JBoss Configuration

Domain Controller Setup

<security-realm name="LdapSSLConnection">  
<authentication>  
<ldap connection="ldapremote" base-dn="ou=People,dc=maxcrc,dc=com" recursive="true"> <username-filter attribute="uid"/>   
</ldap>   
</authentication>  
</security-realm>  

2. Create a new outbound connection whereby we provide details on the host and SSL port the LDAP server is listening on along with the credentials of the user who has permission to search the directory server as below. In this case, the user cn=Manager,dc=maxcrc,dc=com has administrative permissions to perform searches.

<outbound-connections>  
<ldap name="ldapremote" url="ldaps://dwinters-pc:636" searchdn="cn=Manager,dc=maxcrc,dc=com" search-credential="secret"/>  
</outbound-connections>  

3. We now need to configure the native and http management interfaces to use the new LDAP security realm.

<management-interfaces>  
<native-interface security-realm="LdapSSLConnection">  
<socket interface="management" port="${jboss.management.native.port:9999}"/>  
</native-interface>  
<http-interface security-realm="LdapSSLConnection">  
<socket interface="management" port="${jboss.management.http.port:9990}"/>  
</http-interface>  
</management-interfaces>  

4. The last step is to configure each server running on the domain controller node with the location of the truststore and the password. We do so by providing these details via the system-properties element on each server.

<server name="server-one" group="main-server-group">  
<system-properties>   
<property name="javax.net.ssl.trustStore" value="C:\Users\dwinters\Downloads\jboss-eap-6.1\jboss-eap-6.1\domain\configuration\client.keystore"/>  
<property name="javax.net.ssl.trustStorePassword" value="password"/>  
</system-properties>  
</server>  

Remote Host Controller

There is no special configuration needed on the remote controller node. Since access to the management interfaces is performed on the domain controller node, we just need to specify in the host controller configuration file (host.xml) the address of the domain controller of the cluster and the encryted password of an authenticated LDAP user via the server-identities element so that this node can register successfully with the domain controller as below:

<domain-controller>  
<remote host="${jboss.domain.master.address:<remote_host_name>" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealmNative" username="davew"/>  
</domain-controller>  

<server-identities>  
<secret value="<encryptedpassword>"/>  
</server-identities>  

Testing 

We will now attempt to login on the domain controller node to the management administration console and using the jboss CLI tool using the details of a user stored on the LDAP server. In the Figures below, we can observe that when we navigate to the management console on http://<hostname>:9990/console, we are prompted for the LDAP user details and also when we login to the jboss CLI tool we are once again prompted for the username and password.

If you encounter any issues while authenticating users and wish to debug exceptions further, it is very useful to switch on debug logging on the Java SSL packages which will provide details on where the connection is failing between the JBoss server and LDAP server, whether this be a failure to negotiate a common cipher suite between the jboss server and LDAP server or otherwise. To turn on debug logging, set this Java command line property in the domain.conf file on the domain controller node:

 -Djavax.net.debug=all  

Next steps

We could further extend the JBoss configuration above to use its vault utility so that plain text passwords which are in the domain controller configuration files are stored in a password keystore hosted on the domain controller node. The setup and use of vault is quite straightforward and provides an extra layer of security to store sensitive details. 

Introduction  

Building RHQ 

Configuring Maven

• MAVEN_HOME=$where_you_installed_it
• MAVEN_OPTS=“-Xms256M –Xmx768M –XX:PermSize=128M –XX:MaxPermSize=256M”
• PATH=$PATH:$MAVEN_HOME/bin

Configuring PostgreSQL

 CREATE DATABASE rhq;  
 CREATE DATABASE rhqdev;  
 CREATE USER rhqadmin WITH PASSWORD ‘rhqadmin’;  
 GRANT ALL PRIVILEGES ON DATABASE rhq to rhqadmin;  
 GRANT ALL PRIVILEGES ON DATABASE rhqdev to rhqadmin;  

Get RHQ

 git clone https://github.com/rhq-project/rhq.git   

Building and starting RHQ

 mvn -Penterprise,dev -Ddbsetup -DskipTests install   

Setting up and Starting WildFly

Configuring RHQ to Monitor WildFly

Wrapping Up

Why we need a Strong GlassFish

Optimism for the Future

Over 6 months have passed and I've been trying to take stock of where we are. I've recently hosted a community Community Q&A session with Reza Rahman and the London GlassFish User Group and  organised a BOF at Devoxx UK with David Delabassee to get the community involved in what is happening with GlassFish. We've watched the code archives and started our own builds. 

As David Blevins from Tomitribe rightly blogged  open source software is not free and needs community support. It is with this in mind that C2B2, even though we are vendor independent, will be hiring and dedicating some engineers to work on the core GlassFish code base for our support customers. We will also work to mobilise community involvement in GlassFish through Java EE and GlassFish user groups and we are kicking off a BOF at Java One

A Strong GlassFish - read more
Configuring JBoss Management authentication with LDAP over SSL - read more

Latency: The performance killer

Data Grids

Parallel processing on the Grid

Fast Data: Parallel processing on the Grid