Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Google Chose Jetty for App Engine

Google Chose Jetty for App Engine

Leia em Português

This item in japanese

Google App Engine was initially using Apache Tomcat as their webserver/servlet container but eventually switched to Jetty. This decision sparked many in the development community to ask why the change, was their something wrong with Tomcat? InfoQ had the opportunity to interview the team at Webtide, the company behind Jetty, to get the details behind the decision. 

InfoQ: Why did Google choose Jetty over Tomcat, and possibly others, for App Engine?

The key features that Google would have chosen jetty for were size and flexibility. In the cloud, size is important, because if you are running 10s of thousands of instances of jetty (as Google are), then every MB saved per server is 10s of GBs less memory needed (or more memory available for applications).
Jetty is also designed to be pluggable and extensible, so Google have been able to customize it to a high degree. They have plugged in their own HTTP connector, Google authentication and their own session clustering. Strangely enough, these same features mean that as well as being great for the cloud, jetty is really good for embedding in small devices likes phones and set top boxes.

InfoQ: What makes Jetty an efficient servlet container for Java?

When we develop jetty, we do not think of it as a full application server (even though it is one). Each feature is considered pluggable, so that if it is not needed, then it is not loaded into memory and not in the calling chain of the request handling. If you don't need sessions, the session handler can be removed so we don't even waste the cycles looking for a session cookie. When you are handling thousands of requests per second, even small trivial lookups are expensive.
We also do not take for granted the optimization of code by design and we take it with a grain of salt every time somebody tells us how good JVMs are now at optimization and garbage collection. This may be true, but carefully crafted code can still be optimized better and it's still best to avoid creating object. For example, we are using the concurrent techniques in Jetty, but we do not use many of the standard concurrent data structures as they create too many objects. So for example, instead of concurrent linked lists, we use dual concurrent lock circular arrays, so we have the benefits of non blocking concurrency without object creation.

InfoQ: What makes a Jetty a useful server for developers (i.e. testing)?

Jetty is the already built into frameworks like GWT, scala/lift, grails, jruby and many more. So if you use those technologies, you get Jetty out of the box. The jetty-maven plugin is also another excellent developer tool that allows web applications to be run without assembling the components into a war file. Source files can be directly edited and the results tested without waiting for a war file to be built. The embedded nature of Jetty also makes it trivial to write a main that can be directly executed by your IDE, debugger and/or profiler.

InfoQ: What's unique about the way that Jetty handles client-server requests?

Jetty is now a second generation asynchronous server. We've been able to handle request asynchronously now for over 2 years and it is part of our core architecture. As other containers add support for asynchronous servlets, I think they are going to find that it is not as easy/simple as it looks. Our async HTTP engine has also be reused in our async HTTP client, so we can now scalable produce request and consume responses.
Also, as I've previously mentioned we handle requests with an extensible and pluggable handler mechanism, which allows the features of a web application to be individually omitted, used and/or extended.

InfoQ: What are some other examples of Jetty usage, big and small?

Our use companies like Zimbra/Yahoo means that Jetty is serving web mail to many millions of users. The embedding in the eclipse IDE means that jetty is run on the desktop of millions of developers. Jetty is used by hadoop map/reduce cluster which runs on thousand node clusters and holds the world record for sorting a terrabyte of data. We have J2ME ports and native cross compiles so we run on mobile phones, domestic routers and java cards! For a sample of other jetty powered projects see

InfoQ: What's the future/road map look like for Jetty?

Jetty immediate road map is the get a jetty 7.0.0 release out, to complete our move to the eclipse foundation. Jetty 7 will support a lot of the features of servlet 3.0, but without using the new API or requiring java 1.6. Soon after jetty-7, we will release jetty-8 with will be servlet-3.0 and java 1.6 Jetty will also continue to innovate and track the innovations of others in the web 2.0 space. We are now adding support for Firefox 3.5 cross domain Ajax and will use that in cometd. We will soon be adding either WebSocket support and/or BWTP support. Good support of Google wave and associated protocols is also high on our agenda.

InfoQ: Are there any additional plans for Google/Jetty?

Google keep their plans pretty close to their chest, so we don't really know. We've had a bit of a chat to the App Engine developers at JavaOne and we opened the door to any feedback from them as to how to improve the embeddability and extensibility of Jetty.

In a follow-up discussion with the Webtide team, InfoQ also inquired about the decision SpringSource made to choose Tomcat over Jetty.

InfoQ: Any idea why SpringSource is changing Grails to use Tomcat as the default container instead of Jetty?

The reason given was that the grails lead developers feel they can get better "service" on issues from internal tomcat developers. I suspect this is really just about driving grails users towards a platform that SpringSource can sell support services for. We saw a similar thing with JBoss replacing Jetty with Tomcat several years ago when they hired some tomcat developers and ended the commercial arrangement with Mort Bay. It's a pity that such commercial arrangements are having such influence over technical decisions, but we do appear to be in phase where infrastructure projects are aggregating into application server centric groupings.
Grails will continue to support both jetty and tomcat integrations, but will move to tomcat hosting mode by default.

It seems like a decent conclusion especially with SpringSource's use/relationship with Tomcat.

Rate this Article