The fix for https://youtrack.jetbrains.com/issue/KTOR-6292 in ktor 2.3.5 just broke our integration tests. I did a bit of detective work to figure out a work around. Apparently, a fixed thread pool was removed in favor of using Dispatch.IO. Our tests which concurrently (using multiple threads) fire lots of http request at elasticsearch (using my kt-search library) now start randomly timing out I narrowed it down to this change. 2.3.4, tests pass fine. 2.3.5, loads of tests now time out. The diff that introduces this change is here: https://github.com/ktorio/ktor/compare/2.3.4...2.3.5#diff-e93374365f2e47f5ad6229ab678ec20faa17534416dbfadb70154f39d561afe3L23 I worked around it by setting kotlinx.coroutines.io.parallelism=128 According to the documentation, the default for that in the IO dispatcher should be 64, which is a lot higher than the now deprecated threadsCount of 20 that I used to have. The explanation I have is that apparently we were already using the IO dispatcher in a lot of other places. I'm not crazy about having this hardwired. IMHO I should be able to configure the dispatcher explicitly instead of having that hardwired. That's what the previous version did with a fixed threadpool and a threadsCount parameter. Why not just pass in a dispatcher at client creation time with Dispatchers.IO as the default? BTW. The reason I use the Java client is because the CIO client also is a bit flaky under heavy concurrency (KTOR-5697). I just checked this and this is still an issue.

Hey @Jilles van Gurp, thanks for the report! Setting

threadsCount

is a good solution. Having multiple dispatchers with different thread pools could lead to switching threads (possibly multiple time) for a single coroutine (code path). It can introduce noticeable delays in the low utilised workflows and consume cpu. That’s why we try to stick with the

Dispatchers

from `kotlinx.coroutines`: switching between

Default

and

IO

dispatchers shouldn’t have this issue, but custom thread pool dispatchers can. If you have any ideas on how we can improve this, please let me know

As I outlined. Make the dispatcher configurable and default it to the Dispatchers.IO one.

Using pure

<http://Dispatchers.IO|Dispatchers.IO>

is probably not a good idea as it can lead to thread starvation. Neither is using a separate thread pool due to reasons mentioned. Always use

<http://Dispatchers.IO|Dispatchers.IO>.limitedParallelism(...)

instead. For details, see https://github.com/JetBrains/skiko/issues/823