You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Aleksey Shipilev (JIRA)" <ji...@apache.org> on 2007/10/22 13:55:50 UTC
[jira] Commented: (HARMONY-4990) [classlib][nio] file descriptors
leak while work with connections
[ https://issues.apache.org/jira/browse/HARMONY-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536636 ]
Aleksey Shipilev commented on HARMONY-4990:
-------------------------------------------
Running this test on RHEL4 (2.6.9) and Harmony with strace:
[pid 23940] socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 908
[pid 23940] fcntl64(908, F_GETFD) = 0
[pid 23940] fcntl64(908, F_SETFD, FD_CLOEXEC) = 0
[pid 23940] poll([{fd=51, events=POLLIN|POLLPRI, revents=POLLIN}], 1, 100) = 1
[pid 23940] accept(51, {sa_family=AF_INET6, sin6_port=htons(51285), inet_pton(AF_INET6, "::ffff:127.0.0.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 909
[pid 23940] poll([{fd=909, events=POLLIN|POLLPRI, revents=POLLIN}], 1, -1) = 1
[pid 23940] recv(909, "\1", 1, 0) = 1
[pid 23940] close(909) = 0
[pid 23940] write(1, "\r857 ", 5^M857 ) = 5
Notice two sources of new sockets - one with ID=908, second with ID=909.
"socket 909" is closed then, but "908" remains unclosed
> [classlib][nio] file descriptors leak while work with connections
> -----------------------------------------------------------------
>
> Key: HARMONY-4990
> URL: https://issues.apache.org/jira/browse/HARMONY-4990
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: linux
> Reporter: Sergey Dmitriev
> Attachments: manyconnections.java
>
>
> As it turned out a simple test that just accepts connections and then
> closes them eats file descriptors on Linux. The test is attached.
> Talking details:
> Every connection which is accepted on server side causes two FDs to
> be created:
> {bear@serverbox:~/test} lsof -P | grep java
> ...
> java 19776 bear 99u IPv6 1357132 TCP serverbox:9999->clientbox:55117 (ESTABLISHED)
> java 19776 bear 99u sock 0,4 1358043 can't identify protocol
> ...
> 2. After the closing of the connection the first FD gets closed
> but not the second one ("can't identify protocol"). It remains to stay
> "used" till the end of process:
> {bear@serverbox:~/test} lsof -P | grep java
> java 19776 bear 96u sock 0,4 1356827 can't identify protocol
> java 19776 bear 97u IPv6 1356828 TCP *:9999 (LISTEN)
> java 19776 bear 98u sock 0,4 1356829 can't identify protocol
> java 19776 bear 99u sock 0,4 1358043 can't identify protocol
> java 19776 bear 100u sock 0,4 1358218 can't identify protocol
> java 19776 bear 101u sock 0,4 1358220 can't identify protocol
> java 19776 bear 102u sock 0,4 1358222 can't identify protocol
> java 19776 bear 103u sock 0,4 1358224 can't identify protocol
> java 19776 bear 104u sock 0,4 1358226 can't identify protocol
> java 19776 bear 105u sock 0,4 1358228 can't identify protocol
> java 19776 bear 106u sock 0,4 1358230 can't identify protocol
> java 19776 bear 107u sock 0,4 1358232 can't identify protocol
> java 19776 bear 108u sock 0,4 1358234 can't identify protocol
> java 19776 bear 109u sock 0,4 1358236 can't identify protocol
> java 19776 bear 110u sock 0,4 1358238 can't identify protocol
> So in case of consequent connections the server at some point runs out of FDs.
> This definitely impacts the SPECjAppServer2004. There we have pretty
> big amount of connections and at some time the server just cannot
> accept new ones. So it is impossible to do long enough runs (one hour
> steady state as noted in Run&Reporting Rules of SPECjAppServer2004).
> Here is the mini test usage case:
> {bear@serverbox:~/test} ulimit -n
> 1000
> {bear@serverbox:~/test} cat /proc/sys/fs/file-nr
> 1335 0 262144
> {bear@serverbox:~/test} ~/harmony586381/bin/java manyconnections server
> 901 Uncaught exception in main:ava.net.BindException: The address is not available
> at org.apache.harmony.luni.platform.OSNetworkSystem.acceptStreamSocketImpl(OSNetworkSystem.java)
> at org.apache.harmony.luni.platform.OSNetworkSystem.acceptStreamSocket(OSNetworkSystem.java:259)
> at org.apache.harmony.luni.net.PlainSocketImpl.accept(PlainSocketImpl.java:104)
> at java.net.ServerSocket.implAccept(ServerSocket.java:262)
> at org.apache.harmony.nio.internal.ServerSocketChannelImpl$ServerSocketAdapter.accept(ServerSocketChannelImpl.java:265)
> at org.apache.harmony.nio.internal.ServerSocketChannelImpl$ServerSocketAdapter.access$0(ServerSocketChannelImpl.java:258)
> at org.apache.harmony.nio.internal.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:154)
> at manyconnections.runServer(manyconnections.java:25) at manyconnections.main(manyconnections.java:14)
> {bear@clientbox:~/test} /export/jdk1.6.0/bin/java manyconnections client serverbox
> 955 java.net.ConnectException: Connection refused
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.