handles (sockets)

[bokeer]

In a long-running process, when I create new Impit instances repeatedly, the number of open handles (file descriptors) keeps increasing.

Even after the requests have finished, the OS-level handles (sockets) are not released, and eventually the process hits system limits with errors like “too many open files”.

I could not find any documented or exposed close() / destroy() / shutdown() API for the nodejs client, so it’s unclear how an Impit instance is supposed to be properly cleaned up.

[barjin]

Hello and thank you for your interest in this project @bokeer .

Can you please provide a reproduction scenario for this? Preferably one using a local server, so we can confidently reproduce the bug.

Thank you!

[bokeer]

Thank you for the reply. I have narrowed down the cause of the issue.
​It appears to be related to a large pool of impit instances I created. During initialization, each instance tests different proxy IPs, which triggers a high volume of IPv6 DNS resolution requests at the Rust layer. These DNS queries are not returning results (hanging), causing the file descriptor (handle) count to climb steadily until it hits the macOS limit of 10,260, at which point the application fails to create new handles and throws errors.
​One point I would like to clarify: I am currently assigning null to deprecated impit instances to trigger garbage collection. I am unsure if this approach reliably prompts Node.js to notify the Rust layer to drop the instances and close the associated handles. Any insights on the lifecycle management between the two layers would be greatly appreciated.

[barjin]

I am currently assigning null to deprecated impit instances to trigger garbage collection.

Yes, losing all references to the Impit instance from the Node.JS should be enough to drop the Rust structs and all their owned data (provided that our upstream dependencies handle this correctly).

Given the new evidence, this doesn't sound like an issue in impit. If you think otherwise, let's discuss this - I'll keep this issue open for some more time.

[bokeer]

jdtest (1).txt
​To help pinpoint the root cause, I’ve attached some logs that I captured during the crash. I noticed a massive amount of pending DNS queries and handle growth right before the process hit the limit.
​I am still a bit concerned that relying solely on Node.js GC might be too 'slow' for a high-concurrency scenario, leading to a race condition where handles are created much faster than they are released. Could you take a look at these logs and see if they point to a specific bottleneck in the Rust layer or a potential leak in the upstream DNS dependencies?

[bokeer]

I wanted to provide an update regarding the crash I reported.

At the time of the incident, I was using version 0.7.6. I have just upgraded to the latest version (0.8.x) today, and I’m happy to report that the issue has completely disappeared. The massive handle growth and DNS bottlenecks are no longer occurring under the same high-concurrency conditions.

Best regards

[barjin]

Thank you for letting us know @bokeer . Since the issue seem to have been solved, I'll close this ticket now. Feel free to share any additional information if you see fit.

Cheers!