Hi Bill,
On 21/10/15 18:18, Bill Burke wrote:
>
>
> 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 s
>> 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.
>
>
That is an interesting analysis. But I've heard some thoughts recently
though that JAX-RS is good for these nearly basic services but for
something serious - well something needs to be used. IMHO it is
important to position JAX-RS as a technology capable of supporting major
server applications. So if adding NIO can help then I guess it would be good
Cheers, Sergey