lasterra Blog

Grizzly is a framework to develop "Java Servers". We are not going to develop a server, but we are going to see the possibilities that Grizzly offers us inside Glassfish.

Thanks to Grizzly new recently borned projects like JRuby or Phobos are provided with an enviable yield and a solid and stable base for his extensive use in Glassfish as an HTTP connector. This was the initial idea, give HTTP support to the Sun Application Server 8.1, to work without another Web Server (Apache / Sun ONE Web Server)

Grizzly, according to his authors, obtains excellent yields thanks to the fact that it uses the "new" IO API we got in the JDK1.4: NIO. This API also contribute to develop asynchronous server which can turn out to be very interesting as we will see next.

In addition to its throughput, Grizzly is tremendously "programmable". In the Weblog of Jean-Francois Arcand you can find a lot of information. I emphasize things as the aptitude to develop a bandwidth control quota per application or to gain access to the layer of HTTP connections to be able to realize things as the "new" Comet applications.

These applications consist of push information from the server to the navigator without need of requests on the client side. This push is possible becouse the server register and support a connection opened by the users who are subscribed to the information that will be sent. The clearest example a web chat like GMail, where the conversation of one user is sended to the other user connected to the chat without interaction.

The first step to build comet application is configure the http-listener. In the default installation of Glassfish V2 there are two listeners, one for  http and one https. Comet application need cometSuppor property on the http-listener-1 with value true. In the V2 beta 2 there is a bug solved on >=b51, so we have to remove the property proxiedProtocols, that seems that it does not take very well with the support of Comet.

Once our server is prepared we are going to use an example of chat developed by Jean-Francoise and commented in his blog. The servlet pf the comet application of the example, should be instantiated, and its method init executed before the application start, so we must add to the servlet config in the web.xml the property <load-on-startup>0</load-on-startup>. Thus we obtain the context or Path(CometContext) where all the connection of subscribers will be atached when the application start. We can say that the CometContext is the link of Comet API with Grizzly.

super.init (config);
contextPath = config.getServletContext () .getContextPath () + "/chat";
CometEngine cometEngine = CometEngine.getEngine ();
CometContext context = cometEngine.register (contextPath);    
context.setExpirationDelay (20 * 1000); 

Once the servlet has begun and therefore we have the context comet, the users can gain access to the chat. When this happens the example registers the name of the user in the sessión and forward to the page chat.jsp, composed by two iframes.

The first one is the screen where there appear the messages of the users of the chat. We can say that this iframe is the comet client. When this iframe call to the servlet it sendi the parameter openchat. When this request arrive to the servlet a CometHandler is created. This interface that we must implement is the link between our application and Grizzly. It takes care of the cycle of life and the events / notifications generated in the context. Also it has the possibility of attach resources of the application to make use of them on the handler. The common case is to enclose the output streams  (HTTPServletResponse or PrintWriter) to send the information to the client.
Once we have created the handler, We have to add it to the context linking this way the user to the comet, more concretely his HTTP connection .

CometRequestHandler handler = new CometRequestHandler ();
handler.clientIP = request.getRemoteAddr ();
handler.attach (response.getWriter ());
cometContext.addCometHandler (handler); 

All the events that take place in the comet context throught CometContext.notify () operation will be sent as events to the handler of the user (Typical implementation of the Observer Pattern). These events are generated from the second iframe, who send messages to the chat. The servlet in this case, translates the messages of the users in an event thrown to all the users linked to the context. As i said before this is achieved calling operation notify and therefore generating a call to onEvent operation CometHandler interface.

cometContext.notify ("[" + username + "]" + message + " "); 

The operation onEvent from the Handler receives as parameter the last interface of this small API, the CometEvent. Under this interface it's stored all the information of the CometContext and the attached object to the notification, in the example, the message sent by some user. As the handler already has the necessary resources to send the information to the users, it pnly have to forward the attached information to the client.

printWriter.println (event.attachment ());
printWriter.flush ();

And this is all, I believe that it is a good idea to download the example and test it. It has more thing that those i comment in the post, but basically there are only three interfaces implementing Observer Pattern. I have some ideas where i can put these technology in practice...