Grizzly 2.2 now available!

We’ve finally released 2.2! There’s a few features/changes I’d like to highlight here.

I’ll start with the fact that this release is not binary compatible with 2.1. Items to be aware of:

  • CloseListener interface updated in order allow developers to distinguish between a local or remote close.
  • Methods that accept CompletionHandlers no longer return Futures and methods that return Futures no longer accept CompletionHandlers. This was a fairly large change so I won’t go into which files were touched. While we understand this may be a point of frustration, we did reap some performance benefits and added API clarity from doing so. Please see revision 0d5f62 for details and how this may impact your project.

With the not-so-pleasant part out of the way, let’s talk about the fun stuff that’s been added.

Non-Blocking Sendfile Support

We now can support FileChannel.transferTo() to send files to a socket. This feature is available in the core framework and is easy to use. See the following for details:

  • FileTransfer represents the intent to send a file via FileChannel.transferTo(). Simply create the instance, write it to the connection.
  • offers a concrete example of this feature.

We’ve also exposed this feature within the http-server module. Sendfile support will be enabled automatically if the underlying platform will support it properly. Sendfile support will be available if the underlying OS is not HP-UX or if the OS is Linux and the underlying JDK is 1.6.0_18 or newer. However, you can force the issue by enabling/disabling the feature via NetworkListener.setSendFileEnabled(boolean).

We’ve taken a page out of Tomcat’s playbook with how we’ve exposed this feature to developers. I’ll let the documentation explain…

So a typical example would look like:

Grizzly 2.2 Transport for Apache Thrift

Contributed by Bongjae Chang. Please see Bongjae’s blog entry on this topic for details.

RFC 6455: The Websocket Protocol

We’re up-to-date with respect to the Websocket RFC. We can somewhat back up this claim by stating 2.2 passes the Autobahn Websocket Server Test Suite. I’ll be sure to either post the results on our project page, or see if I can talk the Autobahn folks into including the results on their site as they do for Jetty.

Write I/O Thottling

We’ve added a new interface to allow throttling of write I/O to prevent overloading the async write queue and potential OOM situations

Our sample shows this Interface in action.

Async HTTP Client

The next version of Async HTTP Client, 1.7.0, is close to being released. This will be the first release that offers a Grizzly-based provider (based on Grizzly 2.2). However, a new feature worth mentioning here is that this release will include WebSocket support! Again, taking advantage of the work by the Autobahn folks, we’ve run our WebSocket client implementation against their test suite and have passed. Once 1.7.0 goes final, I’ll create another blog entry with details!

Improved Performance

I touched on performance briefly when I covered binary compatibility. We’ll post some numbers in a follow up once we’ve been able to distill and generate some graphs.

I think that about covers it. The full change log for this release can be found here. Questions or concerns? Please feel free to contact us via the mailing lists!

This entry was posted in Java and tagged , , , , . Bookmark the permalink.

4 Responses to Grizzly 2.2 now available!

  1. Imre says:

    I see, the class ServletHandler has been changed and cannot let me to add own Servlet instances and configure them from code.

    Is there any possibility to have this functionality in 2.2?

  2. Ryan Lubke says:

    Ah, right. I forgot to mention this in the binary compatibility section. I’ll be sure to update it. We did indeed make changes here to improve the API.

    See to get the basics of the new API. If you’re familiar with Servlet 3.0 at all, it should feel similar.

  3. Imre says:

    Thanks. :)

  4. Pingback: Grizzly 2.2 release, open source Java NIO framework - Open News