On 10/21/2015 12:20 PM, Markus KARG wrote:
>> 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.
>
You can't reduce the thread pool to one in JAX-RS. You need a thread
pool to execute dispatched requests.
>
>> 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.
>
You're making an exaggeration again. JAX-RS is synchronous
request/response, HTTP, not async messaging. I just don't think NIO
fits with HTTP/REST/JAX-RS. If you actually needed the scalability (and
that is a HUGE if), you'd go use something more low level like Netty.
Besides, this isn't 15 years ago when the Linux kernel could only handle
1-2000 threads. Threads are much more lightweight now and the kernel is
much better at scheduling.
Most of scalability can be handled internally by the OS or the HTTP
container.
>> 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.
>
No, what it tells you is that a NIO interface is only useful in edge
cases (large payloads). IN the majority of REST applications I/O can be
completely buffered as the payloads are small and are already on the
wire to be consumed. So, basically NIO with JAX-RS could possibly (not
probably) be useful for the small tiny percentage of apps have *BOTH*
really high-load and large payloads.
I'm just not convinced adding NIO is justified for such a small edge case.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com