Program exit caused by file descriptor exceeding limit

[KasdllS]

Describe the bug Example "simple_reverse_proxy" exited because of fd over the limit.

To Reproduce Steps to reproduce the behavior:

1. Turn off the WIFI or Plug out the cable.
2. Startup the program.
3. Send HTTP request using short connection.
4. See Many sockets in CLOSE_WAIT.

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [ubuntu 18.04]
• Compiler [gcc 7.5]

Additional context The reason may be that when 'Socket::connect' return a ENETUNREACH error, the TcpClient will never be destoryed. HttpClientImpl create a TcpClient and set 'retry_' to false.Then the Connector of TcpClient tries to connect, but gets a ENETUNREACH error. The Connector will not add itself to a new Channel unless it gets EINPROGRESS or else. No one handles the ENETUNREACH error. HTTP requests using the reverse proxy HttpClientImpl will remain in the buffer queue forever.

[marty1885]

Hi, @KasdllS

This happens when you create way too many sockets in a short time. The typical solution is to reuse the same HTTP client for all of your requests going to the same host. Unfortunately there's almost nothing we can do in this case. It's the OS stopping the application creating more sockets. And drogon can't just block the application and wait for sockets. That will impact performances elsewhere.

[KasdllS]

Hi, @KasdllS

This happens when you create way too many sockets in a short time. The typical solution is to reuse the same HTTP client for all of your requests going to the same host. Unfortunately there's almost nothing we can do in this case. It's the OS stopping the application creating more sockets. And drogon can't just block the application and wait for sockets. That will impact performances elsewhere.

Hi, @marty1885

I'm sorry my wording made you misunderstand me.If you use a long connection to send an HTTP request, set 'timeout' to 0, follow the steps I write above. You will find that the HTTP request blocked, because drogon will never return a response. If you closed your HTTP client, the socket will turn to the CLOSE_WAIT state and remain in this state until it is reclaimed by the system after hours.

[chengyangkj]

Describe the bug Example "simple_reverse_proxy" exited because of fd over the limit.

To Reproduce Steps to reproduce the behavior:

1. Turn off the WIFI or Plug out the cable.
2. Startup the program.
3. Send HTTP request using short connection.
4. See Many sockets in CLOSE_WAIT.

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [ubuntu 18.04]
• Compiler [gcc 7.5]

Additional context The reason may be that when 'Socket::connect' return a ENETUNREACH error, the TcpClient will never be destoryed. HttpClientImpl create a TcpClient and set 'retry_' to false.Then the Connector of TcpClient tries to connect, but gets a ENETUNREACH error. The Connector will not add itself to a new Channel unless it gets EINPROGRESS or else. No one handles the ENETUNREACH error. HTTP requests using the reverse proxy HttpClientImpl will remain in the buffer queue forever.

我这边也发现了这个问题。 在wifi网络很差没信号的时候 ， 使用提供的反向代理示例，我这边写了个文件描述符监控脚本，发现会出现大量的处于CLOSE_WAIT状态的socket。在我不去设置tcp_keepalive_time，要等到2个小时之后这些端口才会被系统渐渐回收。这些socket被慢慢累积到进程的默认最大描述符限制数(1024)时，drogon的日志中有sockets::createNonblockingOrDie与大量的too many open files打印，最终导致程序意外退出。