Jetty’s basic architecture

Jetty is currently a more promising servlet engine, and its architecture is compared Simple, it is also an extensible and very flexible application server. It has a basic data model. This data model is Handler. All components that can be extended can be added to the Server as a Handler. Jetty will help you manage these Handler.

The basic architecture of Jetty

The figure below is the basic architecture of Jetty. The core components of Jetty consist of two components: Server and Connector. The entire Server component is based on the Handler container. It is similar to Tomcat’s Container. The comparison between Jetty and Tomcat will be described in detail later. Another indispensable component in Jetty is the Connector, which is responsible for accepting client connection requests and assigning the requests to a processing queue for execution.

Figure 1. Jetty’s basic architecture

There are some dispensable components in Jetty, and we can expand on it. Like JMX, we can define some MBeans and add them to the Server. When the Server starts, these Beans will work together.

Figure 2. Class diagram of Jetty’s main components

From the figure above, we can see that the core of Jetty is built around the Server class. The Server class inherits Handler and is associated with Connector and Container. Container is the container for managing MBeans. Jetty’s Server extension is mainly to implement Handlers one by one and add Handlers to the Server. The Server provides access rules for calling these Handlers.

The life cycle management of all components of Jetty is based on the observer template design, which is similar to Tomcat’s management. The following is the class diagram of LifeCycle

Every component will Hold an observer (here is the Listener class, this class usually corresponds to the Observer role commonly used in the observer pattern. For the observer pattern, please refer to the article “Tomcat System Architecture and Design Patterns, Part 2: Design Pattern Analysis” About the explanation of the observer mode) set, these Listeners will be called when an event such as start, fail, or stop is triggered. This is the simplest design method, which is much simpler than Tomcat’s LifeCycle.

Handler’s architecture

The aforementioned Jetty is mainly designed based on Handler. The Handler’s architecture affects all aspects of Jetty. The following summarizes the types and functions of Handler:

Figure 3. Handler architecture ( View larger image)

Jetty mainly provides two Handler types, one is HandlerWrapper, which can delegate a Handler Give another class to execute. If we want to add a Handler to Jetty, then we must delegate this Handler to the Server to call. With the ScopeHandler class, we can intercept the execution of the Handler. Before or after calling the Handler, we can do some other things, similar to Valve in Tomcat; the other Handler type is HandlerCollection, this Handler class can assemble multiple Handlers together, A Handler chain is formed to facilitate our expansion.

Back to top

< p>Jetty’s startup process

The entry point of Jetty is the Server class. When the Server class is started, it means Jetty can provide you with services. Which services it can provide depends on the start method of other components is called when the Server class is started. From Jetty’s configuration file, we can find that the process of configuring Jetty is the process of configuring those classes to Server. The following is the startup sequence diagram of Jetty:

Figure 4. Jetty startup process

Because all components in Jetty inherit LifeCycle, the start method call of Server will call all the components that have been registered to Server. The order in which Server starts other components is : First start the Handler set to the Server. Usually this Handler will have many sub-Handlers, and these Handlers will form a Handler chain. Server will start all Handlers on this chain in turn. Then the Mbean registered in the JMX on the Server will be started, so that the Mbean will work together, and finally the Connector will be started, the port will be opened, and the client request will be accepted. The startup logic is very simple.

Back to top

< p>Accept requests

As an independent Servlet engine, Jetty can provide web services independently, but it can also be integrated with other web application servers, so it can provide work based on two protocols, one is HTTP and the other is It is the AJP agreement. If Jetty is integrated into Jboss or Apache, then Jetty can be made to work based on the AJP mode. The following describes how Jetty works based on these two protocols, and how they establish connections and accept requests.

Works based on HTTP protocol

If there is no other web server in the front end, Jetty should work based on HTTP protocol. That is, when Jetty receives a request, it must parse the request and encapsulate the returned data according to the HTTP protocol. So how does Jetty accept a connection and how does it handle this connection?

We set Jetty’s Connector implementation class to org.eclipse.jetty.server.bi.SocketConnector to let Jetty work in BIO mode. Jetty will create a BIO working environment when it starts, and it will create HttpConnection The class is used to parse and encapsulate the HTTP1.1 protocol. The ConnectorEndPoint class handles connection requests in a BIO processing mode. ServerSocket is to establish a socket connection to accept and transmit data. Executor is a thread pool for processing connections. It is responsible for processing each request in the queue. Task. AcceptorThread is to monitor connection requests. Once there is a socket connection, it will enter the following processing flow.

When the socket is actually executed, HttpConnection will be called. This defines how to pass the request to the servlet container, and how to route the request to the destination servlet. For details, please refer to “Servlet Working Principle Analysis” article.

The following figure is a sequence diagram of Jetty starting to establish a connection:

Figure 5. A sequence diagram of establishing a connection

Jetty requires three steps to create an accepting connection environment:

1. Create a queue thread pool to process each task generated by establishing a connection. This thread pool can be specified by the user. This is similar to Tomcat.
2. Create a ServerSocket to prepare to accept the client’s socket request, and some auxiliary classes used by the client to wrap this socket.
3. Create one or more listening threads to monitor whether there is a connection to the access port.

Compared with Tomcat to create a connection environment, Jetty’s logic is simpler, involves fewer classes, and executes less code.

When the connection establishment environment is ready, you can accept HTTP requests. When the Acceptor receives the socket connection, it will be transferred to the process shown in the following figure:

Figure 6. Sequence diagram for processing connection

Accetptor The thread will create the ConnectorEndPoint for this request. HttpConnection is used to indicate that this connection is an HTTP protocol connection. It will create the HttpParse class to parse the HTTP protocol and create Request and Response objects that conform to the HTTP protocol. The next step is to hand over this thread to the queue thread pool for execution.

Working based on AJP

Usually, the back-end server of a web service site does not directly expose the Java application server to service visitors, but instead is in front of the application server, such as Jboss. Add a web server, such as Apache or nginx. I think this reason should be easy for everyone to understand, such as log analysis, load balancing, permission control, prevention of malicious requests, and static resource preloading.

The following figure is a typical web server architecture diagram:

Figure 7. Web server architecture ( View larger image)

Under this architecture, the servlet engine does not require parsing and packaging The returned HTTP protocol, because the parsing of the HTTP protocol has been completed on the Apache or Nginx server, Jboss only needs to work based on the simpler AJP protocol, which can speed up the response speed of the request.

Comparing the sequence diagram of the HTTP protocol, we can find that their logic is almost the same. The difference is that a class Ajp13Parserer is replaced instead of HttpParser, which defines how to handle the AJP protocol and which classes are needed to cooperate.

In fact, the only difference between AJP processing request and HTTP is how to convert the socket data packet when the socket data packet is read. It is HttpParser that is parsed according to the packet format of the HTTP protocol. AJP protocol to analyze is Ajp13Parserer. The same is true for the data returned by the package.

To make Jetty work under the AJP protocol, you need to configure the implementation class of the connector as Ajp13SocketConnector. This class inherits the SocketConnector class and overrides the newConnection method of the parent class in order to create an Ajp13Connection object instead of HttpConnection. The following figure shows the sequence diagram of Jetty creating the connection environment:

< p>The only difference from the HTTP method is that the SocketConnector class is replaced with Ajp13SocketConnector. The purpose of changing to Ajp13SocketConnector is to create the Ajp13Connection class, indicating that the current connection uses the AJP protocol, so the Ajp13Parser class needs to be used to parse the AJP protocol, and the logic for processing the connection is the same. As shown in the timing chart below:

Works based on NIO

The previously described Jetty connection between the client and the client is based on the BIO method. It also supports another NIO processing method. The default connector of Jetty is the NIO method.

For the working principle of NIO, please refer to the article on NIO on developerworks. Usually the working prototype of NIO is as follows:

 Selector selector = Selector.open(); ServerSocketChannel ssc = ServerSocketChannel.open(); ssc.configureBlocking( false) ; SelectionKey key = ssc.register( selector, SelectionKey.OP_ACCEPT ); ServerSocketChannel ss = (ServerSocketChannel)key.channel(); SocketChannel sc = ss.accept(); sc.configureBlocking( false ); SelectionKey newKey = sc.register( selector, SelectionKey.OP_READ ); Set selectedKeys = selector.selectedKeys(); 

Creating a Selector is equivalent to an observer , Open a server-side channel, register the server channel to the observer and specify the event to be monitored. Then traverse the observer to observe the event, take out the event of interest and then process it. The core point here is that we don’t need to create a thread for each observer to monitor its events at any time. Instead, these observers are registered in one place for unified management, and then it sends the triggered events to the interested program modules in a unified manner. The core here is to be able to uniformly manage the events of each observer, so we can manage the transmission and reception of data for each established connection on the server as an event, so that it is not necessary for each connection to require a thread. Maintained.

When you need to pay attention here, many people think that listening to the SelectionKey.OP_ACCEPT event is already a non-blocking way. In fact, Jetty still uses a thread to listen to the client’s connection request. When the request is received, it This request is then registered on the Selector, and then it is executed in a non-blocking manner. There is also a misunderstanding in this place: it is believed that Jetty will only have one thread to handle all requests when working in NIO mode, and even think that different users will share a thread on the server side, which will lead to the appearance of ThreadLocal-based programs. The problem, in fact, from the source code of Jetty, it can be found that the process of truly sharing a thread is only monitoring the data transmission events of different connections. For example, multiple connections have been established. The traditional way is that when there is no data transmission, the thread is blocked. It is always waiting for the arrival of the next data, and NIO’s processing method is that only one thread is waiting for the arrival of all connected data, and when a certain connection data arrives, Jetty will assign it to the processing thread corresponding to this connection to process , So the processing threads of different connections are still independent.

Jetty’s NIO processing method is almost the same as Tomcat’s, the only difference is how to allocate the monitored event to the corresponding connection processing method. From the test results, Jetty’s NIO processing method is more efficient. The following is the timing diagram of Jetty’s NIO processing:

Back to top

Processing the request

Let’s take a look at how Jetty handles an HTTP request.

In fact, Jetty’s working method is very simple. When Jetty receives a request, Jetty passes the request to the proxy Handler registered in the Server for execution. How to execute your registered Handler is also determined by You specify that what Jetty has to do is to call the handle (String target, Request baseRequest, HttpServletRequest request, HttpServletResponse response) method of the first Handler you registered. What to do next is completely up to you.

To be able to accept a web request access, you must first create a ContextHandler, as shown in the following code:

 Server server = new Server(8080); ContextHandler context = new ContextHandler(); context.setContextPath("/"); context.setResourceBase("."); context.setClassLoader(Thread.currentThread().getContextClassLoader()); server.setHandler(context); context.setHandler(new HelloHandler()); server.start(); server.join (); 

When we type http://localhost:8080 in the browser, the request will be proxied To the handle method of the Server class, the handle method of the Server delegates the request to the handle method of the ContextHandler, and the ContextHandler calls the handle method of the HelloHandler. Is this calling method similar to the working method of Servlet? It is initialized before starting, and then the service method of Servlet is called after the object is created. In the Servlet API, I usually only implement a packaged class of it. The same is true in Jetty. Although the ContextHandler is also just a Handler, this Handler is usually implemented by Jetty for you. We generally only need to implement some of our specific The Handler related to the business logic to be done is just fine, and some procedural or certain standardized Handlers, we just use it directly. For example, the following Handlers about Jetty support Servlet specifications have multiple implementations, the following is A simple HTTP request process.

Access the code of a servlet:

 Server server = new Server(); Connector connector = new SelectChannelConnector(); connector.setPort(8080); server.setConnectors(new Connector[]{ connector }); ServletContextHandler root = new ServletContextHandler(null,"/",ServletContextHandler.SESSIONS); server.setHandler(root); root.addServlet(new ServletHolder(new org.eclipse.jetty.embedded.HelloServlet("Hello")),"/"); server.start(); server.join(); 

Create a ServletContextHandler and add a Servlet to this Handler, here The ServletHolder is a decoration class of Servlet, which is very similar to the StandardWrapper in Tomcat. The following is the sequence diagram of requesting this Servlet:

Figure 8. The sequence diagram of Jetty processing the request

The above figure shows that the process of Jetty processing the request is the execution process of the handle method on the Handler chain. The point that needs to be explained here is the ScopeHandler Processing rules, ServletContextHandler, SessionHandler and ServletHandler all inherit ScopeHandler, then these three classes form a Handler chain, and their execution rules are: ServletContextHandler.handleServletContextHandler.doScope SessionHandler. doScopeServletHandler. doScopeServletContextHandler. doHandleSessionHandler. . doHandleServletHandler. doHandle, its mechanism allows us to do some extra work in doScope.

Back to top

< p>Integration with Jboss

Previously, Jetty can work based on the AJP protocol. In normal enterprise applications, Jetty as a servlet engine is based on the AJP protocol, so there must be a server in front of it. , Under normal circumstances, the possibility of integrating with Jboss is very large, here is how to integrate with Jboss.

Jboss is based on the JMX architecture, so any system or framework that conforms to the JMX specification can be added to Jboss as a component to extend the functions of Jboss. Jetty, as the main Servlet engine, certainly supports integration with Jboss. The specific integration method is as follows:

Jetty as an independent Servlet engine integrated into Jboss needs to inherit the AbstractWebContainer class of Jboss. This class implements the template mode, and one of the abstract methods needs to be implemented by subclasses. It is getDeployer, you can specify the Deployer that creates the web service. There is a jetty-jboss module in the Jetty project. Compiling this module will generate a SAR package, or you can download a SAR package directly from the official website. After decompression as shown below:

Figure 9. jboss-jetty directory

There is a webdefault.xml configuration file in the jboss-jetty-6.1.9 directory, this file is Jetty’s default web.xml configuration, found in the META-INF directory The jboss-service.xml file, this file configures the MBean, as follows:

The same org.jboss.jetty.JettyService class is also succeeded to org.jboss.web.AbstractWe The bContainer class overrides the startService method of the parent class. This method directly calls jetty.start to start Jetty.

Back to top

< p>Comparison with Tomcat

Tomcat and Jetty are both widely used as a servlet engine. They can be compared to the relationship between China and the United States. Although Jetty has grown into an excellent servlet engine normally, The current status of Tomcat is still difficult to shake. In comparison, they all have their own advantages and disadvantages.

After a long period of development, Tomcat has been widely accepted and recognized by the market. Compared with Jetty, Tomcat is relatively stable and mature. Especially in enterprise-level applications, Tomcat is still the first choice. But with the development of Jetty, Jetty’s market share is also increasing. As for the reason, it is due to many advantages of Jetty, and these advantages are also reflected by Jetty’s technical advantages.

Architecture comparison

In terms of architecture, Jetty is obviously simpler than Tomcat. If you don’t know the architecture of Tomcat very well, I suggest you read the “Tomcat System Architecture and Design Patterns” this article.

Jetty’s architecture can be seen from the previous analysis that all its components are implemented based on Handler, and of course it also supports JMX. But the main function extension can be realized with Handler. It can be said that Jetty is a Handler-oriented architecture, just like spring is a Bean-oriented architecture, iBATIS is a statement-oriented architecture, and Tomcat is built with multi-level containers, and their architecture design must have a “primordial spirit”. The other components constructed by this “primordial spirit” are all flesh.

From the perspective of design templates, the design of Handler is actually a chain of responsibility mode. The interface class HandlerCollection can help developers build a chain, and another interface class ScopeHandler can help you control the access sequence of this chain . Another design template used is the observer mode. This design mode controls the entire Jetty life cycle. As long as you inherit the LifeCycle interface, your objects can be handed over to Jetty for unified management. So extending Jetty is very simple and easy to understand. The simplicity of the overall architecture also brings great benefits. Jetty can be easily extended and tailored.

In contrast, Tomcat is a lot bloated. The overall design of Tomcat is very complicated. As mentioned earlier, the core of Tomcat is the design of its container, from Server to Service to engine and other container containers. As an application server, it’s not unreasonable to design this way. The layered design of the container is also for better expansion. This way of expansion is to expose the internal structure of the application server to external users, so that if you want to expand Tomcat, develop The staff must first understand the overall design structure of Tomcat, and then know how to expand in accordance with its specifications. This intangible increases the cost of learning Tomcat. Not only the container, in fact, Tomcat also has a design method based on the chain of responsibility, like the Vavle design of the serial pipeline is also similar to the Jetty Handler. To implement a Vavle by yourself is as difficult as writing a Handler. On the surface, Tomcat is more powerful than Jetty because Tomcat has already done a lot of work for you, and Jetty only tells you what you can do and how to do it.

For example, like a child learning mathematics, Tomcat tells you the result of 1+1=2, 1+2=3, 2+2=4, and then you can get 1 according to this method +1+2=4, you must calculate other numbers according to the formula it gives you. Jetty tells you the algorithm rules of addition, subtraction, multiplication and division, and then you can do the calculations yourself according to this rule. So once you master Jetty, Jetty will become extremely powerful.

Performance comparison

It is not very meaningful to simply compare the performance of Tomcat and Jetty. It can only be said that under certain usage scenarios, its performance is different. Because they face different usage scenarios. From an architectural point of view, Tomcat has more advantages in handling a few very busy connections, which means that if the life cycle of the connection is short, the overall performance of Tomcat is higher.

Jetty is just the opposite, Jetty can handle a large number of connections at the same time and can maintain these connections for a long time. For example, some web chat applications are very suitable for using Jetty as a server. For example, Taobao’s web Wangwang uses Jetty as the Servlet engine.

In addition, because Jetty’s architecture is very simple, as a server, it can load components on demand, so that unnecessary components can be removed. This intangible can reduce the memory overhead of the server itself, and processing a request can also reduce the generation Temporary objects, so the performance will be improved. In addition, Jetty uses NIO technology by default to handle I/O requests. Tomcat uses BIO by default. When processing static resources, Tomcat’s performance is not as good as Jetty.

Feature comparison

As a standard Servlet engine, they all support standard Servlet specifications, as well as Java EE specifications. Because Tomcat is more widely used, it The support for these is more comprehensive, and many features of Tomcat are directly integrated. But Jetty’s changes are more rapid. This is because Jetty’s development community is more active. On the other hand, it is also because Jetty’s modification is simpler. It only needs to replace the corresponding components, and the overall structure of Tomcat is much more complicated. , The modification function is slow. So Tomcat’s support for the latest Servlet specification is always later than people expected.

Back to top

< p>Summary

This article introduces Jetty, a popular application server in the current Java server, introduces its basic architecture, working principle and how to work with Jboss, and finally compares it with Tomcat. When reading this article, it is best to combine the two articles I wrote earlier, “Tomcat System Architecture and Design Patterns” and “Analysis of Servlet Working Principles” and the source code of these systems. Take a look at it patiently and let you know Java The server has a general understanding.

Reference materials

Learning

• View the article “Tomcat System Architecture and Design Patterns” (developerWorks, May 2010): Understand the architecture of the container in Tomcat, the basic working principle, and an introduction to the classic design patterns used in Tomcat. 
• Servlet工作原理解析，（developerWorks，2011 年 2 月）：以 Tomcat 为例了解 Servlet 容器是如何工作的？ How does a Web project start in the Servlet container? How does the servlet container parse the servlet you defined in web.xml? How is the user’s request allocated to the specified Servlet? How does the servlet container manage the servlet life cycle? You will also learn about the class hierarchy of the latest Servlet API and the analysis of some difficult problems in Servlet. 
• Tomcat vs Jetty，对 Tomcat 与 Jetty 的做了比较。 
• HTTP 协议，W3C 关于 HTTP 协议的详细描述。 
• developerWorks Java 技术专区：这里有数百篇关于 Java 编程各个方面的文章。 

讨论

• 加入 developerWorks 中文社区。 Check out blogs, forums, groups, and wikis promoted by developers, and interact with other developerWorks users.

关于作者