Should long-running I/O operations be offloaded from Netty event loop threads in Ktor applications? #15021
Replies: 1 comment 1 reply
-
|
In general, you want to leave the event loop to focus on network IO and processing pipeline messages. All blocking operations should be avoided in the event loop, be it taking locks, waiting on futures to complete, or waiting on some other blocking IO operation to complete, e.g. a database call. It's also worth considering moving CPU intensive operations out, but this is a trade-off. Moving tasks between threads have some overhead, but piling too much work on the event loop threads will instead make it less responsive to IO and other messages. As for Kotlin, people have reported some weird behaviors with suspending functions, so I suggest treading carefully. We are not Kotlin experts in the Netty team, so we are not really sure what's special or weird about suspending functions. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi All!
I'm working on a Kotlin server using Ktor with the Netty engine. I know that Netty is a non-blocking, event-driven networking engine and uses a small set of event loop threads shared across all connections.
From what I understand:
Netty event loop threads are designed for lightweight tasks like accepting connections, parsing HTTP requests, and writing responses.
These threads should not be used for long-running tasks, even if they are suspending functions in Kotlin.
🧠 My Questions:
Thanks in advance 🙌
Beta Was this translation helpful? Give feedback.
All reactions