Servlet中的异步功能

Question

I was just going back to Servlet-3.x features and exploring it. If I am not wrong, before Servlet-3.x it was thread per request model and it would run out of threads in the pool, for heavy incoming traffic.

So, with Servlet-3.x it says it is Asynchronous and doesn't keep the threads blocked , rather releases them immediately but just the task is delegated.

Here is my interpretation,

consider there are 2 threads in Server thread-pool

For a new Async Servlet request R1 there is a thread T1 , this T1 would delegate the task to T2 and T1 responds back to client immediately.

Question: Is T2 created from Server thread-pool? If so, I don't get the point.

• Case 1: If it was old Synchronous Servlet request T1 would have been busy running I/O task,

• Case 2: If it was Asynchronous Servlet call T2 is busy running I/O task.

• In both cases, one of them is busy.

I tried to check the same with a sample Async servlet in openliberty app server, below is the sample log captured from my sample demo Servlet.

Entering doGet() == thread name is = Default Executor-thread-116
Exiting doGet() == thread name is = Default Executor-thread-116
=== Long running task started ===
Thread executing @start of long running task = Default Executor-thread-54
Thread executing @end of long running task = Default Executor-thread-54
=== Long running task ended ===

As shown above, the Default Executor-thread-116 is released immediately and delegated long running task to the Default Executor-thread-54 , but I am not sure if they are from the App Server thread pool. If so, why can't just Default Executor-thread-116 do the task instead of delegation?

Can someone throw some light on this async behavior of Servlets in JavaEE

Answer 1

In your example, where the work is synchronous and there's no separate executor/threadpool, there is nearly no point to use async servlets. Lots of samples/examples out there are just block on a 2nd thread because they're trying to illustrate just the syntax.

But there's no reason why you can't spin off a thread to do a little work, add your async context to some list, and then after some event (inbound JMS, websocket, whatever) provides the data needed to complete the async response. For example, a 2-player game server wouldn't wait for player 2 in a second thread, it would just have their async context floating around in memory waiting for a 2nd player to find it.