TCP Socket File Descriptor Leak
See original GitHub issueKtor Version
1.1.5
Ktor Engine Used(client or server and name)
raw sockets
JVM Version, Operating System and Relevant Context
macOS, linux openjdk version “1.8.0_212” OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_212-b03) OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.212-b03, mixed mode)
Feedback
It seems like client tcp socket connections are not properly closed and leaking file descriptors. When testing the server with telnet no leak occurs. The issue is within the client code. The server part is only included for a complete, reproducable example.
Do the read and write channel need separate closing or is something else not handled correctly in the example?
The output is:
Server said: 'hello 0'
open file descriptors: 64
Server said: 'hello 1'
open file descriptors: 67
Server said: 'hello 2'
open file descriptors: 71
Example:
fun main() = runBlocking {
val osMxBean = ManagementFactory.getOperatingSystemMXBean() as UnixOperatingSystemMXBean
val address = InetSocketAddress("127.0.0.1", 2323)
val connectJob = launch {
// repeatedly connect to the server
repeat(3) {
delay(1_000)
aSocket(ActorSelectorManager(Dispatchers.IO)).tcp().connect(address).use { socket ->
val input = socket.openReadChannel()
val output = socket.openWriteChannel(autoFlush = true)
output.writeStringUtf8("hello $it\r\n")
val response = input.readUTF8Line()
println("Server said: '$response'")
}
println("open file descriptors: ${osMxBean.openFileDescriptorCount}")
}
}
// server - irrelevant for the issue
val serverJob = launch {
aSocket(ActorSelectorManager(Dispatchers.IO)).tcp().bind(address).use { server ->
while (true) {
val socket = server.accept()
launch {
socket.use {
val input = socket.openReadChannel()
val output = socket.openWriteChannel(autoFlush = true)
while (true) {
val line = input.readUTF8Line()
output.writeStringUtf8("$line\r\n")
}
}
}
}
}
}
connectJob.join()
serverJob.cancel()
}
Issue Analytics
- State:
- Created 4 years ago
- Comments:12 (5 by maintainers)
Top Results From Across the Web
Socket/FileDescriptor Leak When Executing WLS Application ...
On WebLogic Server 12.2.1.1.0 version, you observe file descriptor leak when using HttpURLConnection. This is when a client program running in ...
Read more >Socket file descriptor leaks? - Nim forum
I had a random problem at $dayjob that I decided would be a fun and easy fit to use nim to solve. There's...
Read more >Is there a file descriptor leak when using sockets on a linux ...
I'm a little worried that my java application may block to many file descriptors. Is this possible? Or does java keep these sockets...
Read more >How to identify leaked file descriptors that are shown only as ...
In Linux operating system every file or socket is associated with a file descriptor. Incorrectly closing these could cause a file descriptor leak....
Read more >Fixing File Descriptor Leaks in Long-Lived Servers
Raise the file handle limit. One common answer to this problem is to just raise the limit of open file handles and then...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Found it! The ActorSelectorManager needs to be closed.
I think the documentation here is quite unclear of this fact. In none of the examples in it, it is closed.
Also note that sockets are not closed immediately but they live in state TIME_WAIT for some system-dependant period of time (usually minutes). See TCP states for more details. This is driven by OS and out of our control.