https://kotlinlang.org logo
#ktor
Title
# ktor
j

Jilles van Gurp

10/27/2023, 12:56 PM
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.
e

e5l

10/27/2023, 1:07 PM
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
j

Jilles van Gurp

10/27/2023, 3:30 PM
As I outlined. Make the dispatcher configurable and default it to the Dispatchers.IO one.
o

Oliver.O

11/08/2023, 5:36 PM
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
👍 2
Created KTOR-6462
🙏 1
2 Views