Hi All,
I mostly agree with Bill’s analysis. I don’t think that today the majority of JAX-RS applications will take advantage of NIO, and I believe to a certain extent you can make the same argument about async. However, I suspect this is likely to change going forward with the shift to micro-services and, as suggested by Sergey, this addition better positions JAX-RS as a complete platform to serve all these needs.
Personally, if I need to write a service that requires NIO, I would not like to step out of JAX-RS (e.g., into Servlets) to solve my problem. With better async (reactive) and NIO, JAX-RS becomes a more complete platform.
— Santiago
> On Oct 21, 2015, at 4:33 PM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>
> 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