[GitHub] [cxf] rmannibucau commented on issue #660: [CXF-8263] Support SSEs in MP Rest Client 2.0

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[GitHub] [cxf] rmannibucau commented on issue #660: [CXF-8263] Support SSEs in MP Rest Client 2.0


rmannibucau commented on issue #660:
URL: https://github.com/apache/cxf/pull/660#issuecomment-616679437

   @reta hmm, MP reactive-streams-operators was supposed to redefine (with the same pitfall that it is no more aligned on what people use on the JVM). Seems it hasnt be done but the spec is not yet really part of MP stack I guess, so still a kind of big sandbox ;).
   To be very concrete, today you have 3 kind of (java) users:
   1. JVM ones (java >= 11 in general),
   2. RxJava ones (they don't care of these abstractions cause they lack too much "helpers",
   3. java 8 guys doing what they can (often reactive streams).
   Indeed you can bridge between all these impl, even with the standard servlet or jaxrs reactive API (what this PR does) but it just adds noise in apps and is something to maintain in time, this is why I generally try to care to never add a dependency I don't need, and here it is not really needed.
   A quick note on the interop which is not always "perfect" (got a few issue with different netty libs if netty was not aligned upfront), can be seen as minor but still.
   Then, to be even more concrete, the interesting part of the reactive programming on producer side is the threading and this PR uses common pool which completely breaks the scalability of apps until tuned...on the JVM which prevents the tuning of the app if used anywhere else. So whatever is done, it will need to use a dedicated executor - either in the MP API or through cxf properties/extensions but not the default CXF one which is sized for other kind of requests.
   Then in terms of API you just reimpl it completely (cause reactivestreams is not an impl as Rx can be) so importing reactivestreams for 3 interfaces with 2-3 methods is very luxury IMHO.
   I'd prefer a module next to the default one enabling to unwrap as a reactive impl the cxf impl rather than the opposite which would enable to embrace all cases and drop reactivestreams when java 8 will be deprecated for example.
   Hope it makes sense.

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
[hidden email]