9

I have worked in the construction of a public API that will have a lot of concurrent accesses and one of the aspects that I thought is to use Asynchronous I/O to consider the scalability aspect.

Initially I thought in use Nginx as a HTTP Server (event-driven) because he work in async way, differently of Tomcat. The API will be constructed in Java and for that I thought in use the following components :

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

I have seen many discussions about Servlet 3.0 because the new version has support to asynchronous requests (using NIO). Based in my problem and in the model above, I have some questions:

  1. Is necessary to use Netty.io once that I have plans to use Servlet 3.0 that supports Asynchronous Requests too?
  2. Use an event-driven webserver (ex: Jetty) is different to use a process based webserver like Tomcat 7 (that supports to Servlet 3.0) that isn't an event-driven webserver?
  3. I saw in many sites that Netty.io works in a way where a thread can accept many requests, instead of the classic way of one thread peer request. In the practice, how it works?
  4. Asynchronous request handing (Servlet 3.0) and Non-Blocking IO (NIO) are different concepts? In which way?
  5. I never see a REST API using NIO, is it a good approach? Which potential problems can I will have?
Poulsen
  • 91
  • 1
  • 3

2 Answers2

3

Is necessary to use Netty.io once that I have plans to use Servlet 3.0 that supports Asynchronous Requests too?

No. It should all be handled by the container.

Use an event-driven webserver (ex: Jetty) is different to use a process based webserver like Tomcat 7 (that supports to Servlet 3.0) that isn't an event-driven webserver?

I'm not aware of any such difference. They both implement Servlet 3.0 so to that extent they are both event-driven.

I saw in many sites that Netty.io works in a way where a thread can accept many requests, instead of the classic way of one thread peer request. In the practice, how it works?

It's irrelevant, see (1) above.

Asynchronous request handing (Servlet 3.0) and Non-Blocking IO (NIO) are different concepts? In which way?

Yes. In every way. Too large a question to address here.

I never see a REST API using NIO, is it a good approach? Which potential problems can I will have?

I've rarely seen any need to use NIO at the client end.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • My main doubt is in the difference between NIO and Async Request (Servlet 3.0). – Poulsen Jan 29 '13 at 16:48
  • My public API probably will have many many requests, so I thought that NIO can be a good approach to help in the scalability question, but I'm not right about the best way to solve this: NIO or AsyncServlet. I have noticed that NIO it's a good way to help this problem because the non-blocking thread uses one thread (or few threads) to handle all requests, in other side, AsyncServlet works with one thread peer request with a new thread (callback mechanism) to handle the response. – Poulsen Jan 29 '13 at 16:55
  • 1
    @Poulsen If you're inside a servlet container you don't have the option of using NIO at all. That's *why* they provided `AsyncRequest.` – user207421 Apr 03 '13 at 02:34
2

I would say it's irrelevant to compare Servlet API and NIO. You can implement Servlet API using e.g. Netty (and that is very close to bicycle inventing). Taking into account async nature included into 3.0 I can't see it possible to build effective implementation based on blocking IO. We do not need even investigate sources. Class names like "org.mortbay.jetty.nio.SelectChannelConnector" are quite self-describing.

The same thing about REST. That is another layer. For example, you can setup tomcat to use NIO connector. Basically such configuration change will not be visible at application layer. (I do not consider bugs which sometimes happen).

Serge Bogatyrev
  • 818
  • 4
  • 5