Replies: 4 comments 2 replies
-
I'm guessing this should be for RESTEasy Reactive in Quarkus as RESTEasy doesn't have a |
Beta Was this translation helpful? Give feedback.
0 replies
-
Oh, that's actually true. I was probably misguided by the package name. |
Beta Was this translation helpful? Give feedback.
0 replies
-
@snazy sounds good! Would you like to contribute these? |
Beta Was this translation helpful? Give feedback.
2 replies
-
Closing as it's only related to Quarkus. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I have two proposals to enhance
RestMulti
.I could contribute the necessary code changes.
Produce multiple JSON objects
Currently,
PublisherResponseHandler.StreamingMultiSubscriber
produces a JSON array, where each emitted item is encoded as a JSON array element. For some use cases it is easier to consume a bunch of "bare" JSON objects - i.e. just write the individual JSON objects, possibly separated by a newline. As an option, of course.Proposal to add:
With
encodeAsArray(false)
, the produced JSON would look like this:encodeAsArray(true)
or omitting it would use the current behavior and produce something like this:Configure request-demand
All implementations of
PublisherResponseHandler.AbstractMultiSubscriber
work with a hard-coded request-demand of1
, which means that every emitted item is "produced"/"computed" serially / one-after-the-other. If the computation of individual items takes somewhat longer, possibly waiting for remote resources to reply, it makes sense to use a higher demand to produce multiple items concurrently.For example, if each item takes maybe 250 ms (requesting data from a remote source) to be produced, and 100 items are produced, it currently takes 25 seconds. With a higher concurrency it would take a fraction of that time. I.e. if the use case is known to be not CPU but (async) I/O bound, it might be legit/feasible to use a high demand.
Proposal to add:
Which would pass
123
as the demand for all call sites toSubscription.request
in implementations ofPublisherResponseHandler.AbstractMultiSubscriber
.Beta Was this translation helpful? Give feedback.
All reactions