A modern programming language that makes developers happier.

kotlinlang

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 <http://Dispatch.IO|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 <http://kotlinx.coroutines.io|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 <http://Dispatchers.IO|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 <@UU2J0PJ81>, 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 <http://Dispatchers.IO|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>

Created <https://youtrack.jetbrains.com/issue/KTOR-6462|KTOR-6462>

For the record guys, our company got hit hard by this as well when we upgraded from 2.3.3. It was really unexpected and I couldn't find this change in your release notes (and it's a pretty big change).

In any event, we had to revert back to 2.3.3 and would appreciate if this gets resolved or a timeline in your mind as to when you guys plan to address the ticket?