>You can already decouple CPU intensive operations with current AsyncResponse API.
Yes but you cannot reduce the thread pool from thousands to one, which is the main driver for NIO.
> 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.
Ok so you know a different way to decouple size of thread pool from number of clients? Then you should tell IBM, because this is why they invented NIO back in Java 1.4. If there would be such a way, they would certainly not have invented it.
> 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."
Depending on the CPU power the size is at about 1 to 5 kB. So what does this tell us about NIO? That we need both, Channels and Streams, so the developer can decide.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com