question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

TCP Socket File Descriptor Leak

See original GitHub issue

Ktor 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:closed
  • Created 4 years ago
  • Comments:12 (5 by maintainers)

github_iconTop GitHub Comments

3reactions
fgutmanncommented, May 16, 2019

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.

1reaction
cy6erGn0mcommented, May 14, 2019

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.

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found