Bill,
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.
If you have no blocking operations at all, you only need one thread per LAN card, and one thread per CPU core. What do you want any more threads for?
>
>> 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.
Certainly it is an exaggeration, itended to make clear my vision of highly scalable cloud servers implemented by JAX-RS.
But once you see the beauty of a _real_ NIO-based solution (not the proposal by the spec leads) you will see that it is rather simple to implement, makes cleaner code in the application, and scales perfectly. I actually do not understand why you try to find arguments _against_ this?
>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.
Try it on Windows. ;-)
>Most of scalability can be handled internally by the OS or the HTTP
>container.
I do not share this impression, actually. Once you have a blocking call, neither the OS not the http container can do anything against it, so you're scalability is screwed then.
> 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.
Yes, certainly. But _i am_ talking about large payloads. I have in mind REST servers with PDF and MP4 payloads. I do not want to _take away_ BIO. I want to add NIO _additionally_.
> I'm just not convinced adding NIO is justified for such a small edge case.
Let's agree to disagree here. :-)
-Markus
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com