There are no stupid questions.
If you mean "jax-rs providers", the answer would be "no, but its not
simple". JAX-RS uses InputStream and OutputStream to process/produce
HTTP entities and those APIs are blocking. There is no good way how to
overcome that, InputStream#read(..) can block there is no way how to get
the information whether it will block or don't read if there is no data
to be read.
OutputStream#write is almost the same. The difference is that in
practice, this is not that big a deal, since outgoing connection usually
do caching on different levels and the application already has the data
to be written. Anyway, same statements are valid here - there is no
method which would say whether #write will be blocking and when is no
way how to do write in non-blocking fashion.
There are possibilities how to do this even without support from the
API, but it would most likely require new process for reading/writing
entities (MessageBodyReader and MessageBodyWriter), which is significant
alteration for the apps compared to the spec-compliant approach.
If you mean "jax-rs implementations", I could imagine providing a
support for consuming and producing Publisher<ByteBuffer> (or something
like that) and documenting that MBR/MBW won't be part of the chain if
that happens and see whether that is a useful or popular way how to
design resource methods and include additional support based on that.
Then the answer is just "no".
Regards,
Pavel
On 04/04/2017 18:03, reza_rahman wrote:
> I am sorry if this is a stupid question. Is there actually anything
> stopping providers from starting to implement NIO outside of the
> standard?
>
> -------- Original message --------
> From: Sergey Beryozkin <sberyozkin_at_talend.com>
> Date: 4/4/17 11:17 AM (GMT-05:00)
> To: jsr370-experts_at_jax-rs-spec.java.net
> Subject: [jax-rs-spec users] Re: Proposal to drop non-blocking I/O
> from JAX-RS 2.1
>
> Would it make sense to return to what was available in m01, what
> Santiago originally prototyped, and restrict to the server code only ?
>
> It would be a basic NIO support, without being too involved, yet it
> would allow JAX-RS users to tap into Servlet 3.1 NIO API.
> Future JAX-RS 3.0 (?) based on Java 9 will be Java 9 Flow/etc based
> which will be good, but it will be many years before it will happen.
> In meantime users would use a somewhat limited but yet functional
> server side NIO which will become a 'legacy' API in future JAX-RSs.
>
> IMHO it will be better than having no NIO at all
>
> Sergey
>
>
> On 04/04/17 14:49, Sergey Beryozkin wrote:
>> Hi Pavel
>>
>> It's disappointing even though I appreciate the effort done so far.
>> Probably the most important feature we could've done and now we will
>> face +N (or more) years of waiting for JAX-RS be NIO ready, and by
>> the time it will happen everyone will already be using Spring RS
>> anyway who are charging ahead as we speak with top-class Reactive
>> support...
>> I don't know, we will have though SSE which not all browser
>> implement, I'd rather have only NIO instead of SSE.
>> The 'Flow' duplication argument is not convincing because I believe
>> you had a plan after all to get rid of it when we get to Java 9.
>> The mid of April constraints just highlights that the process once
>> again defeats us completing the work which was planned
>>
>> Thanks, Sergey
>>
>> On 03/04/17 17:40, Pavel Bucek wrote:
>>>
>>> Dear EG members,
>>>
>>> As you all know we have been hard at work trying to come up with an
>>> NIO proposal based on Flows. In doing so, we have come to the
>>> conclusion that this is indeed a really hard problem --lots of small
>>> details that need double clicking! After some deliberation, we have
>>> come to the conclusion that it is better to drop this feature from
>>> this dot release. Here is the rationale for doing so:
>>>
>>> - Working backwards from the officially committed Java EE 8 release
>>> date - July 2017 - we need to start Public Review in the middle of
>>> April, which means that at this point we don't have enough time to
>>> do a design, implementation prototype and gather appropriate feedback.
>>> - Current proposal is based on a Flow-like API, which would force us
>>> to duplicate the JDK 9 Flow concept in the JAX-RS 2.1 API.
>>> - We don't want to introduce "just another non-blocking API", which
>>> might be deprecated very soon (when Java 9 is released).
>>> - We need some time to work on "smaller issues", which would be most
>>> likely not possible if we'll continue working on NIO.
>>>
>>> *What does that mean for the current state of the API?*
>>>
>>> We will remove Flow.* interfaces and its usage in existing APIs,
>>> which means adjustments in SSE part of the spec. Also, we will be
>>> making at least some improvement, more related to already introduced
>>> Reactive API - support for returning CompletionStage from the
>>> resource method. It was in our last version of the high level
>>> non-blocking API; CompletionStage is basically a Mono - publisher of
>>> a single item. Resource method could then look like:
>>>
>>> @POST @Path("acceptProduceSource")
>>> public CompletionStage<AnotherPOJO> echoNioEntity(POJO requestEntity) {
>>>
>>> // not blocking the thread, returning CompletionStage and doing the
>>> work elsewhere. return ...;
>>>
>>> }
>>>
>>> This improvement will simplify use of the new JAX-RS 2.1 reactive
>>> client API in a JAX-RS resource method. Note that this is already
>>> tracked as https://java.net/jira/browse/JAX_RS_SPEC-546.
>>>
>>> As always, any comments or suggestions are appreciated.
>>>
>>> Thanks and regards,
>>> Pavel & Santiago
>>>
>>
>