Socket.close() not freeing resources after send/recv timeout
See original GitHub issueI am running into a problem where jeromq is not freeing resources if the Socket is unable to connect. This is reproducible with the following code:
import org.zeromq.ZMQ;
import org.zeromq.ZMQ.Context;
import org.zeromq.ZMQ.Socket;
public class rrclient {
public static void main(String[] args) {
Context context = ZMQ.context(1);
while (true) {
try (Socket socket = context.socket(ZMQ.REQ)) {
socket.connect("tcp://localhost:33333");
socket.setSendTimeOut(1000);
socket.setReceiveTimeOut(1000);
socket.send("Hello");
String reply = socket.recvStr(0);
if (reply == null) {
System.out.println("TIMEOUT");
} else {
System.out.println("Received reply [" + reply + "]");
}
} catch (Exception e) {
e.printStackTrace();
break;
}
}
context.term();
}
}
Simply run this code without a server listening on the other end, and the process will eventually consume all file handles on the machine. I was able to reproduce this on linux and macos.
Issue Analytics
- State:
- Created 6 years ago
- Comments:18 (9 by maintainers)
Top Results From Across the Web
close vs shutdown socket? - Stack Overflow
close() will terminate both directions on a TCP connection. ... and use close to free up the resources used by the socket data...
Read more >c++ - Network Programming - send/recv and Timeout - Daniweb
1. recv() will NOT necessarily receive all the bytes sent in one call. ... If the connection is closed by the other end...
Read more >Socket Programming HOWTO — Python 3.11.1 documentation
The client sends a request and then does a shutdown(1) . This tells the server “This client is done sending, but can still...
Read more >HTTP Server - ESP32-S2 - — ESP-IDF Programming Guide release ...
Following are detailed steps to use the API exposed by HTTP Server: httpd_start() : Creates an instance of HTTP server, allocate memory/resources for...
Read more >TLSSocket Class Reference - Mbed
... returns connected network socket to call close() that deallocates the resources. Referencing a returned pointer after a close() call is not allowed...
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 Free
Top 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
It looks like ZContext automatically sets linger (to 0 by default) when destroying sockets, but ZMQ.Context does not, which could be part of the issue.
Reproduced it on my machine as well.
Inserting that helps to speed up the failing process:
Setting this line as the last one in the try block fixes the situation: