Grizzly – Infrastructure for COMET and AJAX

Dietrich Kappe, Monday, June 19, 2006 @ 9:00 am

Other than being the black hole into which the JavaMail API has disappeared, the Open Source Glassfish project -- a J2EE app server building on the Toplink and J2EE code donated by Oracle and Sun respectively -- has some interesting stuff under the hood. They have a new NIO-based HTTP Connector named Grizzly. See their Webtier page; down a little on the page, you'll see a heading entitled "HTTP Connector." Along with a nice high level diagram, the section describes Grizzly as

Grizzly is an HTTP Listener using Java's NIO technology and implemented entirely in Java. A re-usable NIO based framework that can be used for any HTTP related operations (HTTP Listener/Connector) as well as non-HTTP operations, thus allowing the creation of any type of scalable multi-threaded server.

With NIO, as anyone who has ever used the Unix select system call, you can have a single thread operating on a bunch of connections instead of one thread per connection. This can save tremendous overhead and can achieve a surprisingly high degree of performance. See the old single-threaded HTTP servers Boa and Tiny httpd for evidence that this is not a new concept.

To understand why Grizzly helps in one piece of the COMET puzzle, we look at Jean-Francois Arcand's blog entry, Can a Grizzly run faster than a Coyote. He ran ApacheBench against Tomcat and Glassfish and came up with the following result: Tomcat needs 500 threads where Grizzly needs only 10 to handle a large benchmark test.

The results are a little controversial -- nobody likes their app server trashed -- and I don't want to get into a discussion about the relative performance of Tomcat vs Glassfish, but the ability to handle the IO of an application server with a small number of threads bodes well for COMET. COMET, remember, keeps a connection open to the browser while the Servlet is performing some long running calculation or waiting on a message, and that means we'll have more connections open at one time. If we needed one thread per connections, we'd be hosed.

What NIO doesn't solve, however, is the that the waiting Servlet still chews up a thread. As we've mentioned previously, Jetty 6 has a continuation mechanism for Servlets that allows waiting Servlets to give up their threads. That's the other part of the puzzle for COMET. Jetty 6, BTW, also has an NIO HTTP Connector to go with its Servlet Continuations, so this may be the way to go for COMET early adopters.

Related posts:

1. Not There Yet: COMET with Apache and Jetty
2. COMET: Socket Hungry AJAX
3. GWT and Comet – Using GWT with Jetty Continuations
4. Comet 2008: The State of Play in Reverse Ajax
5. Roundup – Comet Tutorials, Examples and Resources

Comments (3)

Software Development

Comments: 3 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   For most of the applications that will only be useful when database drivers and other backend connectors will also use NIO.

   Comment by Guillaume, Monday, June 19, 2006 @ 12:40 pm

2. 

   I’ve posted a tutorial on how to get GWT working with Grizzly Comet. Check it out here http://www.javascriptr.com/2008/05/28/gwt-grizzly-comet/

   Comment by mo rock, Wednesday, May 28, 2008 @ 11:23 pm

3. [...] http://weblogs.java.net/blog/jfarcand/archive/2005/06/grizzly_an_http.html http://www.pathf.com/blogs/2006/06/infrastructure_/ http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1301487,00.html [...]

   Pingback by Grizzly Comet - what’s grizzling with comet?? - Part 1, Thursday, December 18, 2008 @ 1:26 am

Leave a comment