This is my 16th day of the August Challenge

This series of code address: github.com/HashZhang/s…

In our project, instead of using the default Tomcat container, we used UnderTow as our container. In fact, the difference in performance is not that obvious, but using UnderTow we can use direct memory as the buffer of network transmission, reduce GC of the service, and optimize the performance of the service. Tomcat also uses direct memory as a buffer for network transmission. Connector uses NIO or NIO2, as well as APR, which is based on JNI to optimize file and request transmission. However, As Tomcat iterates and develops, As functionality becomes more sophisticated and componentized, the architecture becomes more complex, resulting in some reduction in code design and quality. Comparing the source code and design of Tomcat Connector, I finally chose Undertow, which is a lighter design. As for the reasons for not selecting Jetty and Tomcat, the main reason for not selecting Reactor-netty is that the project is still relatively new and not mature, and based on asynchronous callback, the exception handling is not comprehensive in many cases, resulting in weird response and high cost of exception locating.

Undertow’s official website: undertow.io/

  • Red Hat open source product, currently the default Web container for WildFly (JBoss AS).
  • It can show high performance and stability without requiring very complex configurations.
  • Very lightweight, you can quickly set up a Web server using an API.
  • The underlying layer is based on XNIO, which is similar to the Netty design, using NIO as the means of network interaction, and using direct memory as the buffer of network transmission, reducing GC of the business.
  • Because of this asynchronous framework, the configuration is also handed over to chaining handlers to configure and handle requests, minimizing the need to load modules on demand without loading superfluous functionality
  • Support for Servlet 4.0 and backwards compatibility, WebSocket support

But Undertow has some concerns:

  1. The smell of poverty, backed by red Hat, the father of this is not very reliable
  2. The NIO framework is based on XNIO. The 3.0 Roadmap Announcement mentions that XNIO will move from XNIO to Netty starting with 3.0. See Undertow 3.0 Announcement. However, it’s been almost two years now, 3.0 is still not released, and the 3.0 branch on Github has not been updated for over a year. Currently, the 2.x version of Undertow is still in use. I don’t know if 3.0 doesn’t need to be developed right now, or is it stillborn? At present, the domestic environment is more widely used for Netty and most people are more familiar with Netty. XNIO applications are not many. However, XNIO’s design is much the same as Netty’s.
  3. The update of official documents is relatively slow, which may be 1 or 2 small versions slower, resulting in the configuration of Spring Boot glue Undertow is not so elegant. Along with the official documentation, it’s a good idea to take a look at the source code, or at least the configuration classes, to see what’s going on.
  4. A close look at the Undertow source code reveals that there are many defensive programming designs or functional designs that the authors of Undertow thought of, but just didn’t implement, and a lot of unfinished code that hasn’t been implemented. It also raises the question of whether Underow is underpowered and will die suddenly.

However, thanks to Spring-boot, in a Spring-boot project, the cost of switching containers is minimal, just changing dependencies. Also note the configuration of the different Web containers.

Undertow is currently (2.x) based on Java XNIO. Java XNIO is an extension of the JDK NIO class. It has the same basic functionality as Netty, but netty is more of a wrapper around Java NIO. Java XNIO is more like extended encapsulation. The main reason is that the basic data transmission in NetTY is not the ByteBuffer in Java NIO, but the encapsulated ByteBuf, and the interface design of Java XNIO is still based on ByteBuffer as the transmission processing unit. It’s also very similar in design, which is the Reactor model. Its structure is as follows:

Java XNIO consists of the following concepts:

  • Java NIO ByteBuffer:BufferA stateful array used to hold data that can track what has been written or read. The main attributes are capacity(the size of the Buffer), position(the subscript of the next position to be read or written), and LIMIT (the limit at which a Buffer can be read or written).In order to read or write data from a Channel, a program must put data into a Buffer.ByteBufferIs a more specific Buffer that can be allocated in direct memory, so that the JVM can use the Bytebuffer directly for IO operations, saving a copy step (see my article:Java out-of-heap memory, zero copy, direct memory, and thinking about FileChannel in NIO). It can also be allocated directly through file-mapped memory, known as Java MMAP (see my article:JDK core JAVA source code parsing (5) – JAVA File MMAP principle parsing). Therefore, most IO operations are performed through byteBuffers.
  • Java NIO Channel: Channel is a Java abstraction for opening a connection to an external entity, such as a hardware device, a file, a network connection socket, or some component that can perform IO operations. A Channel is primarily an IO event source. All data written or read must go through a Channel. For NIO’s Channel, it goes throughSelectorTo notify the readiness of the event (such as read readiness and write readiness), which is then read or written through the Buffer.
  • XNIO Worker: Worker is the basic network processing unit in the Java XNIO framework. A Worker contains two different thread pool types, which are:
    • IO thread pool, the main callSelector.start()The various callbacks for the corresponding events are handled, and in principle no blocking tasks can be handled because that would cause other connections to fail to process. The IO pool consists of two types of threads. (In the XNIO framework, the pool size is set by setting WORKER_IO_THREADS. By default, it is one IO thread per CPU.)
      • Read thread: callback that handles read events
      • Write thread: the callback that handles write events
    • The Worker thread pool handles blocked tasks. In Web server design, calling servlet tasks are typically placed in this pool (in the XNIO framework, this pool is set by setting WORKER_TASK_CORE_THREADS).
  • XNIO ChannelListener: ChannelListener is an abstraction used to listen for Channel events, including:channel readable.channel writable.channel opened.channel closed.channel bound.channel unbound

Undertow is an XNIO-based Web services container. In addition to XNIO, add:

  • Undertow BufferPoolIf you apply for a ByteBuffer every time you need it, you need to go through the JVM memory allocation process (TLAB -> heap) for heap memory and system call for direct memory, which is very inefficient. Therefore, memory pools are usually introduced. And here it isBufferPool. Currently, there is only one UnderTowDefaultByteBufferPool, the other implementations are currently useless. This DefaultByteBufferPool is very simple compared to Netty’s ByteBufArena, similar to the JVM TLAB mechanism (see my other series:TLAB analysis of the most core JVM in the entire network), but much simpler.All we need to do is configure the buffer size and enable direct memory.
  • Undertow ListenerThe HTTP/1.1, AJP, and HTTP/2 listeners (HTTPS is implemented by the corresponding HTTP Listner with SSL enabled) are built in by default. The Listener is responsible for parsing all requests and wrapping them intoHttpServerExchangeAnd give it to the next oneHandlerTo deal with.
  • Undertow Handler: A complete Web server is formed by handling the response business through Handler.

In this section, we look at the structure of Undertow in detail, explain the benefits and concerns of Undertow, and compare it to other Web containers. In the next section we will examine the detailed configuration of Undertow.

Wechat search “my programming cat” to follow the public account, every day, easy to improve technology, win a variety of offers: