Comparison of jetty and Tomcat _jetty

The Google application engine was originally based on Apache Tomcat as its webserver/servlet container, but eventually switched to Jetty. The decision has surprised many developers by asking why such a change would be made. What's wrong with Tomcat? We were given a chance to visit the company behind Webtide--jetty, and got more detailed information about the decision behind it.

Journalist: Why Google chooses Jetty as its engine for its application, not Tomcat or anything else.

The key reason for Google to choose Jetty is its size and flexibility. In cloud computing, the volume factor is important, if you run tens of thousands of jetty instances (as Google does), each server province is 1 trillion, which saves 10 g of memory (or can provide more memory for other applications).

Jetty is designed to be pluggable and extensible so that Google can customize it in a highly customizable way. They replaced their own HTTP Connector,google authentication, as well as their own session cluster. Oddly enough, this feature is excellent for cloud computing, but it also makes jetty ideal for embedding small devices such as cell phones and set-top boxes.

Journalist: What prompted Jetty to become an excellent servlet container in Java.

When we were developing jetty, we didn't want to develop it into a fully functional application server (although it was). Each feature is considered pluggable, so if you don't need him, you can remove it from the request processing call chain without loading it into memory. If you don't need sessons, you can take the session processor away, so you don't waste resources looking for the session cookie back and forth. When you have thousands of requests per second, the overhead of these tiny search actions is huge.

We have not taken for granted the idea that we can get the optimized code by design, we are like collecting grains of sand, each time we get some people telling us how to have good JVMs optimization and garbage collection. This is true, already careful code can still be optimized, the final effect is to avoid creating new objects. For example, we use parallel processing techniques in jetty, but we do not use many standard parallel processing data structures because it requires creating too many objects. So, just as an example, we use a double parallel lock loop arrays instead of a parallel chain lists, so that we can get non-blocking parallel effects without creating an object.

Journalist: What makes jetty a useful server platform for developers (for example: testing).

Jetty has been built into some popular frameworks, such as Gwt,scala/lift,grails,jruby and much more. If you use these techniques, you can use jetty directly. The Jetty-maven plug-in is another very good development tool that enables Web applications to run without packaging into war files. The source file can be edited directly and the test results are obtained without having to put it back into the war file. Jetty Embedded features let us no longer need to write the boring things by writing those main methods, running through your IDE, debugger or profiler.

Reporter: Jetty is there any unique place in processing Client-server request?

Jetty is now a second-generation asynchronous processing server. Over the past two years, we've let jetty implement the function of processing asynchronous requests, which is part of its core architecture. Like other asynchronous serlets containers, I think they'll find it's not as simple and easy as it seems. Our asynchronous HTTP engine has been reused on HTTP client, so we can reduce request and responses consumption in a large amount.

At the same time, as I mentioned earlier, our request processor is extensible and pluggable, allowing the Web application to be omitted individually, either individually or further extended application.

Journalist: There are no other cases of jetty use, large or small.

Companies using jetty are like Zimbra/yahoo, which means Jetty is serving as a Web mail server for millions users. The Eclipse IDE built it in, which means millions of developers are running jetty on the desktop. Jetty is used by the Hadoop map/reduce cluster, which has thousands of-point clusters that handle the world's largest terabytes of data sorting work. We also have J2ME interfaces that have local compilers, so we can run on mobile phones, home routers, and Java cards. More examples of JETTY use can refer to http://docs.codehaus.org/display/JETTY/Jetty+Powered

Journalist: What is the future or blueprint of jetty?

Jetty's latest plan is to release the 7.0.0 version, which will be completely migrated to Eclipse Foundation. Jetty 7 will support many of the features of the servlet 3.0, but will not use the new APIs and will not rely on Java 1.6. After Jetty 7, we will soon release Jetty 8, which will fully support the continued creation of the servlet 3.0 and Java 1.6,jetty and the tracking of other new results in various Web 2.0. We are now able to support the Cross-domain AJAX functionality in Firefox 3.5, which we can use in the cometd version. We will soon increase our support for WebSocket and BWTP. The issue of support for Google wave and related protocols has been prioritized on our agenda.

Reporter: Google/jetty have any other plans?

Google has a chess game of their own, we don't know. We had a simple conversation with app engine developers at the JavaOne conference, and we were willing to listen to their feedback and comments to improve Jetty's scalability and scalability.

In the following discussion with the Webtide team, we asked about the SpringSource transition from jetty to Tomcat.

Interviewer: How do you see SpringSource changing Grails from a jetty that was originally a default container to Tomcat's business?

The reason is that the leadership of Grails development feels that using Tomcat can get a better "service" from the internal Tomcat developer. I guess they drove grails users to a certain platform so that SpringSource could sell their technical support services better. We saw the same thing a few years ago, and JBoss hired a tomcat developer to put jetty into Tomcat and eventually reached a commercial contract with Mort Bay. Unfortunately, these commercial agreements have such a big impact on technology choices, and when the same is true, some infrastructure projects are also gathering in the application server-centric team.

Rails will continue to support integration of jetty and Tomcat at the same time, but will change to Tomcat as the default service.

This seems to be a particularly appropriate assertion that SpringSource uses/clings to Tomcat.

Original: http://blog.163.com/scuqifuguang@126/blog/static/17137008620147139398337/