Jetty 6: Rewritten for Continuations, NIO, Servlet 2.5

Jetty 6 is a complete re-write, "adding non-blocking without rearchitecting could be done (and was done to jetty 5), but without architectural change non-blocking cost more than it gained." Greg said.   "[It is like a house] ... You try and clean up every so often, but the clutter wins. Finally you give up and move to a new house."

On the new base, many new features have been added, such as Continuations.  The cometd implementation and DWR/ActiveMQ integration are both based on continuations. Integrations are key to Jetty with work being done in respect to Spring, Geronimo, Glassfish, and others. The new architecture made adding new features possible with less volitility to the code base. Finally Wilkins noted that the new buffering abstraction is rather key, allowing Jetty to be deployed in byte[] only environments as well as with the lastest JVM's supporting more advanced buffers.

On Jetty's use of NIO in version 6:

Above the connection layer, Jetty is designed as a non-blocking HTTP parser and generator. This has allowed us to use NIO selectors as a non-blocking scheduler.

But moreover, the rearchitecture has allowed us to use more of the NIO features. Our buffering abstraction allows direct buffer and file mapped buffers to be used when available and when appropriate. We can use gather writes, to send a header, content and trailer in a single NIO call.

But it is important to realize that we are not NIO dependant and that the new architecture should work equally as well on other IO frameworks: existing or future.

Continuations play a big part in the new server, as Greg had suggested in the past that they solve the needs of modern web 2.0 scalability. 

...continuations are a reflection that the needs of scalable web 2.0 cannot be met with the current servlet API.

It has always been a challenge to blend the event driven nature of protocols with the desire for procedural application environments. Continuations are a key mechanism for achieving this and Jetty continuations are a subset of a general continuation targeted specifically at suspending and resuming a HTTP request handler.

Suspend and resume are important in web 2.0, because the request handler is often forced to wait: wait for an event to send to the client (eg google chat); wait for a remote WS; wait for JDBC connection; etc.

With web 1.0, most of the waiting was done in the client or in the TCP connector. With web 2.0, most of the waiting is done within the servlet container. Without finding a cheap way to park requests from within the servlet container, web 2.0 can decrease scalability 10 fold.

With Jetty 6 continuations, we have been able to test to 10k simultaneous requests within the servlet container and we have web 2.0 applications that need this.

Wilkins talks a lot about Web 2.0 and believes that it is more than a technical issue:

Web 2.0 developers are pushing the envelope to develop the best, worst and wierdest UIs possible with the HTTP, HTML, javascript and DOM tools we have available.

The jetty community embraces that exploration of the possible. The response from some other projects to the issues of web 2.0 has been "That's protocol abuse. Don't do it!". But if you come to the Jetty community with a problem that your web 2.0 app is giving you, we will listen, learn and try to adapt. If you want to do it, we want you to do it with Jetty.

Finally we asked about Wilkins about his new company Webtide. He explained the the company allows them to provide 24x7 commercial support, training, and consulting for Jetty and web 2.0 applications. They also have an extended network of OS developers that allows Webtide to cross support a wide range of technologies. The upcoming Hightide Jetty extension will be the first release from the Webtide initiative.