verdier commented on PR #43007: URL: https://github.com/apache/superset/pull/43007#issuecomment-5245091241
Expanded the trade-off section with numbers rather than a caveat, since it is the part that deserves scrutiny. The cliff is exactly at `pool_size + max_overflow`: 15/15 concurrent calls pass in 4s on the stock pool, 16 costs 35s and one `QueuePool limit ... timeout 30.00`, and 20 never finishes — 5 of 20 rows written in 15 minutes before I killed it. Sizing the pool to 40 gives a clean 20/20 in 5s. What makes it a cliff rather than a queue is where the wait happens: the tool bodies do blocking DB work on the event loop, so the task waiting on the pool blocks the same thread as the tasks holding the connections, and they cannot reach their app context teardown to release them. Nothing moves until the 30s timeout fires. Worth noting that oversubscription itself is already normal here and copes fine everywhere else: the web tier is `gthread --threads 20` against the same 15-connection pool, and the MCP sync path goes through anyio's 40-thread limiter against those same 15 — both wait per thread. The async path is the only one where one waiter stops everyone. So the fix is correct but not self-limiting. Two small options in the PR body (semaphore sized from the pool, or running async tool bodies on a worker thread — option 2 from #42622). I did not want to fold a design decision into a bug fix; tell me which you would rather see and I will add it here or send it separately. -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
