REST API with NIO?

Question

I worked on creating a public API that will have many concurrent accesses and one aspect that I thought was to use asynchronous I / O to address the scalability aspect.

At first, I thought that Nginx was used as an event-driven HTTP server, because it works asynchronously, in other words, from Tomcat. The API will be built in Java, and for this I decided to use the following components:

• Tomcat 7 - HTTP / Web Server + Java Container
• Netty.io or HttpCore?
• Resteasy (REST layer, w / HttpServlet30Dispatcher servlet)
• MongoDB (with Java Async driver)

I saw a lot of discussion about Servlet 3.0, because the new version supports asynchronous requests (using NIO). Based on my problem and in the model above, I have a few questions:

• Do I need to use Netty.io once when I plan to use Servlet 3.0, which also supports asynchronous requests?
• Using an event-driven web server (such as Jetty) is different than using a process-based web server such as Tomcat 7 (which supports Servlet 3.0), which is not an event-driven web server.
• On many sites, I have seen that Netty.io works so that a stream can accept many requests, rather than the classic single-threaded peer request method. In practice, how does it work?
• Asynchronous request processing (Servlet 3.0) and non-blocking IO (NIO) are different concepts? How?
• I never see a REST API using NIO, is this a good approach? What potential problems can I have?

Answer 1

Do I need to use Netty.io after I plan to use Servlet 3.0, which also supports asynchronous requests?

Not. All this must be handled by the container.

Is using an event-driven web server (like Jetty) different than using a process-based web server like Tomcat 7 (which supports Servlet 3.0), which is not an event-driven web server?

I do not know any such difference. They both implement Servlet 3.0, so in both cases they are event driven.

On many sites, I have seen that Netty.io works in such a way that a stream can accept many requests, rather than the classic way to request a single stream. In practice, how does it work?

It does not matter, see (1) above.

Asynchronous request transfer (Servlet 3.0) and non-blocking IO (NIO) are different concepts? How?

Yes. In every way. Too big a question to contact here.

I never see a REST API using NIO, is this a good approach? What potential problems can I have?

I rarely saw the need to use NIO on the client side.

Answer 2

I would say that it does not matter to compare the Servlet API and NIO. You can implement the Servlet API using, for example, Netty (and this is very close to creating a bicycle). Given the asynchronous nature included in 3.0, I see no way to build an efficient implementation based on I / O locks. We do not even need to explore the sources. Class names such as "org.mortbay.jetty.nio.SelectChannelConnector" are pretty self-describing.

Same thing in REST. This is another layer. For example, you can configure tomcat to use a NIO connector. Basically, such a configuration change will not be visible at the application level. (I do not consider mistakes that sometimes happen).