Servlet APIs and NiO: finally grouped together

NIO is one of the most famous (if not the most outstanding) additions to the Java platform with JDK 1.4. Many of the following articles describe the basics of NIO and the benefits of using non-blocking channels. But one thing they're missing is that it's not enough to show how NIO can improve the scalability of the Java EE Web layer. For enterprise developers, this information is particularly relevant because the implementation of NIO is not as simple as changing a few import statements into a new I/O package. First, the Servlet API uses blocking I/O semantics, so by default it cannot take advantage of non-blocking I/O. Second, unlike JDK 1.0, threads are no longer "resource exclusive" (Resource hog), so using fewer threads does not necessarily indicate that the server can handle more clients.

In this article, in order to create a WEB server based on servlet and implementing NIO, you will learn how to troubleshoot the servlet API and non-blocking I/O problems. We'll see how this server scales against the standard I/O server (Tomcat 5.0) in a multiple WEB server environment. To meet the reality of the lifetime in the enterprise, we will focus on how NIO compares to standard I/O when the number of clients holding the socket connection grows exponentially.

Note that this article is intended for some Java developers who are already familiar with the basics of I/O programming on the Java platform.

Threads are no longer expensive

As we all know, threads are more expensive. In the early days of the Java platform (JDK 1.0), the overhead of threading was a huge burden, forcing developers to customize build solutions. A common solution is to use the thread pool created when the VM is started, rather than creating each new thread on demand. Although the performance of the threads has recently been improved on the VM layer, standard I/O still requires that a unique thread be allocated to handle each newly opened socket. In the short run, it worked pretty well, but when the number of threads increased more than 1K, the lack of standard I/O was shown. Because of the context switching between threads, the CPU simply becomes overloaded.

Because of the introduction of NIO in JDK 1.4, enterprise developers end up with a built-in solution to the "single-threaded" model: Multiple I/O allows a fixed number of threads to serve the growing number of users.

Multiplexing (multiplexing) refers to sending multiple signals or streams at the same time through a load Polay. The daily Multiplexing example occurs when using a mobile phone. Wireless frequencies are scarce resources, so wireless frequency providers use multiplexing technology to send multiple calls over one frequency. In one example, the call is divided into segments, which are then given a short duration and reassembled at the receiving end. This is called time Division Multiplexing (time-division multiplexing), or TDM.

In NIO, the receiving end is equivalent to "selector" (see Java.nio.channels.Selector). Instead of processing a call, the selector handles multiple open sockets. As in TDM, the selector reassembled the data segments written from multiple clients. This allows the server to manage multiple clients with a single thread.

Servlet APIs and NIO

Non-blocking reading and writing is necessary for NIO, but they are not completely hassle-free. In addition to not blocking, non-blocking reads do not give the caller any assurance. The client or server application may read the full information, part of the message, or the message is not read at all. In addition, non-blocking reads may read too many messages, forcing an extra buffer for the next call. Finally, unlike streaming, reading 0 of bytes does not indicate that the message has been fully received.

These factors make it impossible to implement even simple readline methods without polling. All servlet containers must provide a ReadLine method on their input stream. As a result, many developers have abandoned the creation of a WEB application server that is based on Servlet and implements NIO. But here's a solution that combines the Servlet API and NIO's multiple I/O capabilities.

In the following sections, you will learn how to use the Java.io.PipedInput and PipedOutputStream classes to apply producer/consumer models to consumer non-blocking I/O. When reading a non-blocking channel, write it to the pipeline that is being consumed by the second thread. Note that this decomposition mapping thread differs from most java-based client/server applications. Here, we have a single thread responsible for handling non-blocking channels (producers), so that another thread is solely responsible for streaming the data as a stream consumption (consumer). The pipeline also solves non-blocking I/O problems for the application server because the servlet will use blocking semantics when consuming I/O.

Sample Server

The sample server demonstrates a producer/consumer solution that is incompatible with the Servlet API and NIO. This server, very similar to the Servlet API, provides a POC (proof of concept) for sophisticated NIO application servers and is specifically written to measure the performance of NIO relative to standard Java I/O. It handles simple HTTP get requests and supports keep-alive connections from the client. This is important because multiplexing I/O only proves intentional when the server is required to handle a large number of open scoket connections.

The server is divided into two packages: the Org.sse.server and org.sse.http packages have classes that provide primary server functionality, such as the ability to receive new client connections, read messages, and generate worker threads to handle requests. The HTTP package supports a subset of the HTTP protocol. It is beyond the scope of this article to elaborate on HTTP.

Now let's take a look at some of the most important classes in the Org.sse.server package.