Julien Ponge
Julien Ponge
Looks interesting to me. Is there a prototype available? (note: do not expect any further interaction from me for the next 2 weeks) On Fri, Aug 9, 2019 at 5:46...
I've had a private discussion with @xstefank / I'm not sure I get it all but I'll have another look.
I concur that unless you need to build a big pipeline for each new request, there's no real benefit in caching. I'm still looking at your reproducer, I will ping...
My conclusion is that caching here isn't terribly helpful anyway 😄
It's not been actively maintained but I'll gladly take PRs to make it work with current Gradle versions. It's always been a challenge to go through frequent breaking changes in...
The call to `.await()` (and also `.collect()` to some extent) is the culprit, as this initiates a `Long.MAX_VALUE` demand (aka unbounded)
Also note that the server code blasts through the `Stream` source and pushes items to the `emitter` without honoring any back-pressure. This can be checked with `MultiEmitter::requested`.
You'd need to check `requested()` in a loop, but I confess the API here is not so great. We'd need to add a callback for requests, just like I did...
I created an issue, this will land in Mutiny... soon 😄
`subscribe().with(...)` also does an unbounded request. To properly control the demand I'm afraid you have to create your own subscriber, as in: https://github.com/smallrye/smallrye-mutiny/blob/main/workshop-examples/src/main/java/_01_basics/_14_Multi_Subscriber.java (note that here it's an inefficient 1-by-1...