I do not understand your argument regarding what some people did: I also know a lot of people blocking threads on servers and implement other scalability obstacles and performance killers, but that doesn't make neither performance nor scalability less an argument. If we say "NIO", we have to deliver "NIO", which simply and essentially _means_ single-nonblocked-thread architecture. NIO+InputStream makes simply no sense at all, you can simply not provide _any_ NIO then. You are right, the majority of _developers_ will never _need_ NIO. The reason is that NIO is something _administrators_ need to load more work on a single CPU. It is _the_ default architecture for highly scalability servers, so _every_ non-nonsense administrator will simply expect it to be enabled _by_default_. It even is worse: I totally maked never any sense from the scalability view to provide _blocking_ IO in JAX-RS.
Sorry for my bad English: What means "cycles" in here?
From: Santiago Pericasgeertsen [mailto:santiago.pericasgeertsen_at_oracle.com]
Sent: Dienstag, 20. Oktober 2015 15:30
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: NIO draft
Markus,
I’ve seen people doing exactly what you say it’s not needed. These are likely the same developers using StreamingOutput today —I don’t think it is the majority, but I don’t think it is the majority that need NIO. As I responded to an earlier message to Bill, this is only part of the story. We do need to explore NIO for at least MBR/MBW’s.
Do you have some cycles to explore that use case?
— Santiago
On Oct 19, 2015, at 4:55 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
From my point of view, the main driver for NIO is to massively increase server scalability, which typically is achieved by using less threads, as the amount of threads produces unnecessary overhead for the OS and JVM. Blocking-IO currently demands on thread per request. NIO allows one thread per thousands of requests. The typical NIO solution hence is a container that has a single thread per LAN card. So the actual showstopper in the existing JAX-RS API is not what your examples showcase, but in fact it is:
* WriterInterceptorContext.getOutputStream() --> Uses blocking OutputStream, but must return a non-blocking WriteableByteChannel.
* ReaderInterceptorContext.getInputStream() --> Uses blocking InputStream, but must return a non-blocking ReaderByteChannel.
* ContainerRequestContext.get/setEntityStream() --> Uses blocking InputStream, but must return a non-blocking ReaderByteChannel.
* ContainerResponseContext.get/setEntityStream() --> Uses blocking OutputStream, but must return a non-blocking WriteableByteChannel.
Using a *Channel instead of a *Stream a filter / interceptor can detect potential blocks of the container's LAN card, skip the blocking call, and instead file the request to try again later using CompletableFuture in conjunction with the Java EE container's managed executor service or any other application-wide executor. As you know, this is what typically is called a "multi-fiber" architecture, which is one of the most effective ways to utility NIO on the server side.
In my eyes that scenario (allowing the JAX-RS container to use one single thread per LAN card by replacing *Stream by *Channel, so the thread can do any other work if the LAN card would block) is far more important than the scenarios covered by the examples found in the proposal. In fact, any kind of NIO within the resource class and / or client API should not be part of the API, as it simply is a task of the JAX-RS implementation to leverage NIO within its own source code to prevent blocking at request / response handling. I do not see any need to expose NIO to the application programmer here.
-Markus
From: Santiago Pericasgeertsen [ <mailto:santiago.pericasgeertsen_at_oracle.com> mailto:santiago.pericasgeertsen_at_oracle.com]
Sent: Montag, 12. Oktober 2015 16:30
To: <mailto:jsr370-experts_at_jax-rs-spec.java.net> jsr370-experts_at_jax-rs-spec.java.net
Subject: Drafts for Rx, NIO and SSE
Dear Experts,
My apologies for sending all these drafts in one shot, but I feel we need to start making progress quickly if we want to produce an EDR in a few months.
The following pull request [1] includes proposals for Rx, NIO and SSE. Let me point you to the examples to get you started:
(1) Rx:
<
https://github.com/spericas/api/blob/master/jaxrs-api/src/test/java/javax/ws/rs/core/RxClientTest.java>
https://github.com/spericas/api/blob/master/jaxrs-api/src/test/java/javax/ws/rs/core/RxClientTest.java
This is an extension to our Client API that integrates with the CompletableFuture API in JDK 8 (note that CompletionStage is a super type of CompletableFuture). The proposal is extensible and can use other APIs similar to CompletableFuture —see the optional parameter to the rx() method for that purpose. The spec will only mandate support for CompletableFuture, but implementations are free to provide support for other APIs, such as RxJava.
(2) NIO:
<
https://github.com/spericas/api/blob/master/examples/src/main/java/jaxrs/examples/nio/FileResource.java>
https://github.com/spericas/api/blob/master/examples/src/main/java/jaxrs/examples/nio/FileResource.java
<
https://github.com/spericas/api/blob/master/examples/src/main/java/jaxrs/examples/nio/FileResourceClient.java>
https://github.com/spericas/api/blob/master/examples/src/main/java/jaxrs/examples/nio/FileResourceClient.java
On the server side, the proposal follows the pattern set by StreamingOutput, but of course using lambdas this time around. As you know, Servlet already supports NIO, but with a completely different API.
(3) SSE:
<
https://github.com/mpotociar/api/tree/master/examples/src/main/java/jaxrs/examples/sse>
https://github.com/mpotociar/api/tree/master/examples/src/main/java/jaxrs/examples/sse
Note that like in NIO, there are proposed extensions to both the Client and Server APIs for SSE.
I understand that this is a lot to digest, so feel free to start new e-mail threads to discuss each one independently. I just felt it was important to start all these discussions ASAP.
— Santiago
[1] <
https://github.com/jax-rs/api/pulls>
https://github.com/jax-rs/api/pulls