Existe um vazamento de descritor de arquivo ao usar soquetes em uma plataforma Linux?
-
07-07-2019 - |
Pergunta
Se eu abrir e fechar um soquete ligando, por exemplo
Socket s = new Socket( ... );
s.setReuseAddress(true);
in = s.getInputStream();
...
in.close();
s.close();
O Linux afirma que este soquete ainda está aberto ou pelo menos o descritor de arquivo para a conexão está presente. Ao consultar os arquivos abertos para este processo pelo LSOF, há uma entrada para a conexão fechada:
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
java 9268 user 5u sock 0,4 93417 can't identify protocol
Esta entrada permanece até que o programa seja fechado. Existe alguma outra maneira de finalmente fechar o soquete? Estou um pouco preocupado que meu aplicativo Java possa bloquear muitos descritores de arquivos. Isso é possível? Ou o Java mantém esses soquetes para reutilizá-los até o Reuseadress está definido?
Solução
If those sockets are all in the TIME_WAIT state, this is normal, at least for a little while. Check that with netstat; it is common for sockets to hang around for a few minutes to ensure that straggling data from the socket is successfully thrown away before reusing the port for a new socket.
Outras dicas
You may also want to check /proc/<pid>/fd
, the directory will contain all of your currently opened file descriptors. If a file disappears after you closed the socket you will not run into any problems (at least not with your file descriptors :).
I think it's not your program's problem.
In SUN_Java, when socket related native lib loaded, A MAGIC_SOCK fd will be created.
write on the MAGIC_SOCK will resulted a Connect Rest Exception, and read on the MAGIC_SOCK will resulted a EOF.
the magic_sock's peer has been fully closed, and the magic_sock itself is half_closed, and the state will remain "can't identify protocol".
Maybe it's a socket of some other protocol ("Can't identify protocol" eh?) used internally in the implementation to do something, which gets created on the first socket.
Have you tried repeatedly creating sockets and closing them, to see if these sockets really persist? It seems likely that this is a one-off.
Java probably uses sockets internally for lots of things - they might be Unix, Netlink (under Linux) or some other type of socket.
Create a small bash script to monitor opened sockets for a certain app or pid, and let it run while testing your java app.
I doubt anyway that there are any kind of leaks in this thing as sockets are very used in linux/unix world and this kind of problem would bubble up very quicky