Connection pool based web server with async support vs Event Loop based web server

Question

I'm learning about Vertx and it's ecosysteme, firstly i learned about Event loop, and the concept is really nice to me.

But since Servlet 3.1 we can use async support in JAVA based servers.

I'm using Spring and it's new class named deferredresult which can take thread from tomcat, give execution of logic to thread from executor thread pool that make thread from tomcat free to handle another requests and then when it done return response.

In event loop all blocking calls should be done by worker vertx, the concept is absolute the same, you give a thread to blocking call and provide callback when task is done event loop execute callback and return response.

These concepts looks really similar to me.

Maybe i miss something but what is the difference between these concepts?

Answer 1

Thread pool based web servers use worker threads as the primary execution context for user requests. When you develop a Spring or JavaEE application, you call a lot of blocking code (JDBC, Hibernate, JAX-RS client, ...etc). Then the servlet 3.1 async API was added to solve problems like long polling (if all your worker threads are waiting, you cannot handle requests any more).

Event loop based systems (Vert.x, Node) however are built to handle a lot of user requests with a single thread. Usually you combine them with non blocking database drivers or web clients. It's a very powerful model (less thread migrations, warm caches, ...etc). But you must not block the event loop or you can't handle events any more. In an ideal world you would use only non blocking libraries but reality is many Java libraries are not and we shouldn't just throw this legacy away. As a workaround, Vert.x provides a way to offload blocking code execution to a worker pool.

I hope this clarifies a bit and shows that, beyond the similarities, the use cases are different.