MongoWaitQueueFullException in Webflux + Reactive Mongo

Affects: 5.1.2.RELEASE

---

The latest TechEmpower’s benchmark shows a lot of errors for Webflux + Spring data mongo. I digged and found out that under load, we get a lot of com.mongodb.MongoWaitQueueFullException: Too many threads are already waiting for a connection. Max number of threads (maxWaitQueueSize) of 500 has been exceeded. exceptions.

From our discussion on gitter, @mp911de thinks that “WebFlux could have a notion of connection backpressure and should limit subscription rate/demand rate to provide a sense of protection for downstream components within the application”.

Code of the benchmark here

Related issue : #20338

[simonbasle]

Yes, and I believe that would also be resolved by a reactive DB Connection pooled capped at 500 connections.

[cbornet]

For the current use case here, I think the first step is to have a closer look to understand why Flux.concat does not help. It seems like it should with 100 connections + 500 queue size > 512 concurrency. Only then we can reason about what should change if anything in the configuration.

So using concat instead of merge does have an effect on the number of items put in the wait queue. The number of concurrent connections is related to the queue size (with concat it’s queue size + a little number). The pool size doesn’t seem to have any effect. I guess all items go into the queue before being given a pool connection. I can put a high maxWaitQueueSize (using waitqueuemultiple parameter in connexion string) and then I don’t see any issues both for concat and merge. I think I’ll keep merge with a queue size of 512*20 since it gives better results for low concurrency requests (since the 20 requests are done concurrently). For me this issue is understood and can be closed. Maybe there could be some documentation somewhere about the Mongo async driver pool size. I’ll do the fix for the TechEmpower benchmark. Thanks to all.