AsyncClient read appears to block
- Dominant language
- Kotlin
- Stars
- 2
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Description
I have a lightweight Android app that, at its base, is essentially just spawning connections to an external server. The protocol is: android app opens tcp socket using `createTcpClient`, connects to the server, and sends a greeting; the server acknowledges. Then the connection waits (ideally without blocking a thread) for a message from the server using `AsyncClient.read(buffer, offset, len)`. These connections are spawned inside of individual coroutines on `Dispatchers.IO`, which has a max parallelism of 64 threads.
Using this same architecture and ktor aSockets, I am able to open basically as many connections as I want. Unfortunately, ktor aSockets has a major issue with switching coroutine contexts under the hood such that broken pipe exceptions (which should essentially be meaningless) are unhandleable and thus fatal on Android. (https://github.com/ktorio/ktor/issues/1237)
I found korio, and it seemed like a great alternative, so I swapped ktor out for korio. Unfortunately, I am only able to open a max number of connections equal to the number of threads allocated by `Dispatchers.IO`, which is the same behavior as when using Java blocking Sockets. Hence, it doesn't seem like Kotlin is able to suspend and swap coroutines to create more than 64 connections.
Should I be using a different method other than `AsyncClient.read()` to wait for a message from the server without blocking?
Contributor guide
No contributing guide indexed for this repository
Research direction
Start at AsyncClient.read(buffer, offset, len) and the createTcpClient call path described in the report. Reproduce the connection-limit behavior with coroutines on Dispatchers.IO, then inspect whether read suspends or occupies a thread. Done means establishing whether this is a library defect and documenting or correcting the supported non-blocking usage.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, kotlin
- Domain
- mobile-dev, networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100