-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Reactive request is not properly propagated as cursor batch size #4543
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Project Reactor revised prefetch sizes by quite a bit (e.g. |
@mp911de But that's why I logged the request to thingRepository.findAll()
.doOnRequest { println("Requested $it") }
.limitRate(10)
.collectList() I still end up with
|
Switching from |
We now use Flux.flatMapSequential(…) instead of concatMap as concatMap reduces the request size to 1. The change in backpressure/request size reduces parallelism and impacts the batch size by fetching 2 documents instead of considering the actual backpressure. flatMapSequential doesn't tamper the requested amount while retaining the sequence order. Closes: #4543 Original Pull Request: #4550
We now use Flux.flatMapSequential(…) instead of concatMap as concatMap reduces the request size to 1. The change in backpressure/request size reduces parallelism and impacts the batch size by fetching 2 documents instead of considering the actual backpressure. flatMapSequential doesn't tamper the requested amount while retaining the sequence order. Closes: #4543 Original Pull Request: #4550
@christophstrobl |
@kwazii1231 GH only allows to assign a single milestone. So we pick the 'oldest' version that contains the fix and every version after that (from a date perspective) will also contain it. In this case it will be |
Since the upgrade to Spring Boot 3.1 we noticed a major performance degradation in comparison to our previous Spring Boot 2.7 environment. Now it looks like that the cursor batch size for mongo queries has changed. The old 2.7 service seems to use a default of 32 (24 getMore). The new 3.1 service seems to be using a cursor size of 2.
To reproduce run this litte snippet either with SB 2.7 or SB 3.1
Running this with SB 3.1 results in the following log (with logging.level: org.mongodb: debug)
I don't think this is working as intended, is it?
The text was updated successfully, but these errors were encountered: