[jax-rs-spec users] Re: NIO draft

From: Bill Burke <>
Date: Tue, 20 Oct 2015 20:54:50 -0400

On 10/20/2015 4:19 PM, Markus KARG wrote:
> There is a misunderstanding: NIO is not about performance, it is about scalability.
> NIO does not bring _any_ performance benefit wrt to execution time of a request-response cycle (i. e. number of _sequential_ requests per second).
> NIO only does provide a _dramatic_ improvement of _scalability_ (i. e. number of _parallel_ requests per second), due to the ability to massively reduce the amount of threads needed by the container and due to its ability to decouple I/O-bound operations from CPU-bound operations, which in its aggregate effect drops hardware cost for service providers by far. If you want cloud, you need NIO.

You can already decouple CPU intensive operations with current
AsyncResponse API.

> No _developer_ will ever ask for it. NIO is not an API "feature". NIO is simply an _administrative_ cloud necessity.

Necessity is a gross exaggeration.

> What you talk about will not improve scalability measurably. It will solely make JAX-RS more complex. What you actually need is Channels in all places where you have InputStream/OutputStream currently in the API. Not more, not less.

Here's some feedback from our servlet container developer. Our HTTP
engine/servlet container is NIO based and often in the top 10 of the
techempower benchmarks:

"I think that with MessageBodyReader and MessageBodyWriter this is
something that could provide an improvement for large payloads, and
because these are generally provided by 3rd party libraries they could
potentially provide a behind the scenes benefit without the app
developer needing to know the first thing about NIO (other than marking
their filters async capable).

Depending on the use case though this can actually have a negative
performance impact. For reading small to medium sized payloads the cost
of going async and then re-dispatching back to the container could
outweigh any performance benefit. For async writers this is less of an
issue, as there is no need to dispatch once the write is done."

Bill Burke
JBoss, a division of Red Hat