I am wondering that if servlet containers like Tomcat, Jetty etc already use nio to read and write data back, is there really a need of using setWritelistner
and setReadListner
on servlet input and output streams? Is there any additional performance gain?
In short, an asynchronous servlet enables an application to process incoming requests in an asynchronous fashion: A given HTTP worker thread handles an incoming request and then passes the request to another background thread which in turn will be responsible for processing the request and send the response back to the ...
If a servlet or a filter reaches a potentially blocking operation when processing a request, it can assign the operation to an asynchronous execution context and return the thread associated with the request immediately to the container without generating a response.
Non-Blocking ServletsJetty has good support for asynchronous request processing.
Jetty uses Direct NIO buffers, and allocates threads only to connections with requests. Synchronization simulates blocking for the servlet API, and any unflushed content at the end of request handling is written asynchronously.
The benefit is not directly1 about "performance gain". The purpose of those methods is to avoid a request thread (in async mode) from blocking when it reads input (POST) data or writes the document.
There is an example in the Java EE7 tutorial: "17.13.1 Reading a Large HTTP POST Request Using Non-Blocking I/O" (link updated).
This is orthogonal to Tomcat's use of nio under the covers.
1 - There is an indirect performance benefit. When it is likely for threads to block on network I/O, an alternative strategy for increasing throughput is to increase the number of worker threads. But that increases the memory footprint (among other things) resulting in more "overheads".
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With