You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Sergey Dmitriev (JIRA)" <ji...@apache.org> on 2007/10/22 11:46:50 UTC
[jira] Created: (HARMONY-4990) [classlib][nio] file descriptors
leak while work with connections
[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
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.
[jira] Commented: (HARMONY-4990) [classlib][nio] file descriptors
leak while work with connections
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537009 ]
Tim Ellison commented on HARMONY-4990:
--------------------------------------
Sorry, please verify it is fixed for you Sergey (I thought the thanks were for me :-) )
> [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
> Assignee: Tim Ellison
> 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.
[jira] Updated: (HARMONY-4990) [classlib][nio] file descriptors
leak while work with connections
Posted by "Sergey Dmitriev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sergey Dmitriev updated HARMONY-4990:
-------------------------------------
Attachment: manyconnections.java
> [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.
[jira] Commented: (HARMONY-4990) [classlib][nio] file descriptors
leak while work with connections
Posted by "Mark Hindess (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536806 ]
Mark Hindess commented on HARMONY-4990:
---------------------------------------
Sergey, you can make the patch yourself from the top-level classlib directory by typing:
svn diff -c 587087
where 587087 is the revision number from Tim's comment above.
> [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
> Assignee: Tim Ellison
> 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.
[jira] Commented: (HARMONY-4990) [classlib][nio] file descriptors
leak while work with connections
Posted by "Sergey Dmitriev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537354 ]
Sergey Dmitriev commented on HARMONY-4990:
------------------------------------------
Thanks everybody! :)
> [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
> Assignee: Tim Ellison
> 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.
[jira] Closed: (HARMONY-4990) [classlib][nio] file descriptors leak
while work with connections
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Ellison closed HARMONY-4990.
--------------------------------
Verified by Sergey.
> [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
> Assignee: Tim Ellison
> 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.
[jira] Commented: (HARMONY-4990) [classlib][nio] file descriptors
leak while work with connections
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537013 ]
Aleksey Shipilev commented on HARMONY-4990:
-------------------------------------------
I have verified this issue yesterday, strace shows that sockets are being reused now.
You may close the issue for sure :)
> [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
> Assignee: Tim Ellison
> 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.
[jira] Commented: (HARMONY-4990) [classlib][nio] file descriptors
leak while work with connections
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536640 ]
Aleksey Shipilev commented on HARMONY-4990:
-------------------------------------------
Moreover, I have instrumented ServerSocketChannelImpl.accept like:
public SocketChannel accept() throws IOException {
if (!isOpen()) {
throw new ClosedChannelException();
}
if (!isBound) {
throw new NotYetBoundException();
}
+ System.out.println("xxx phase1");
SocketChannel sockChannel = SocketChannel.open();
+ System.out.println("xxx phase2");
Socket socketGot = sockChannel.socket();
+ System.out.println("xxx phase3");
try {
begin();
synchronized (acceptLock) {
synchronized (blockingLock()) {
boolean isBlocking = isBlocking();
if (!isBlocking) {
// for non blocking mode, use select to see whether
// there are any pending connections.
int[] tryResult = Platform.getNetworkSystem().select(
new FileDescriptor[] { this.fd },
new FileDescriptor[0], 0);
if (0 == tryResult.length || 0 == tryResult[0]) {
// no pending connections, returns immediately.
return null;
}
}
// do accept.
do {
try {
((ServerSocketAdapter) socket).accept(socketGot,
(SocketChannelImpl) sockChannel);
// select successfully, break out immediately.
break;
} catch (SocketTimeoutException e) {
// continue to accept if the channel is in blocking
// mode.
}
} while (isBlocking);
}
}
} finally {
end(socketGot.isConnected());
}
+ System.out.println("xxx phase EXIT");
return sockChannel;
}
And here we go with:
[pid 25007] write(1, "xxx phase1", 10xxx phase1) = 10
===========
[pid 25007] write(1, "\n", 1) = 1
[pid 25007] socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 92
[pid 25007] fcntl64(92, F_GETFD) = 0
[pid 25007] fcntl64(92, F_SETFD, FD_CLOEXEC) = 0
===========
[pid 25007] write(1, "xxx phase2", 10xxx phase2) = 10
[pid 25007] write(1, "\n", 1) = 1
[pid 25007] write(1, "xxx phase3", 10xxx phase3) = 10
[pid 25007] write(1, "\n", 1) = 1
[pid 25007] poll([{fd=51, events=POLLIN|POLLPRI, revents=POLLIN}], 1, 100) = 1
[pid 25007] accept(51, {sa_family=AF_INET6, sin6_port=htons(52162), inet_pton(AF_INET6, "::ffff:127.0.0.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 93
[pid 25007] write(1, "xxx phase EXIT", 14xxx phase EXIT) = 14
[pid 25007] write(1, "\n", 1) = 1
[pid 25007] poll([{fd=93, events=POLLIN|POLLPRI, revents=POLLIN}], 1, -1) = 1
[pid 25007] recv(93, "\1", 1, 0) = 1
[pid 25007] close(93) = 0
[pid 25007] write(1, "\r41 ", 4^M41 )
So this "bogus" socket is created with
SocketChannel sockChannel = SocketChannel.open();
And it does not used in main code (created bogus 92, but receive on 93).
> [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.
[jira] Commented: (HARMONY-4990) [classlib][nio] file descriptors
leak while work with connections
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536653 ]
Aleksey Shipilev commented on HARMONY-4990:
-------------------------------------------
Tim, so I giving up on this issue for now.
What I have digged for the moment:
There are two places where the socket created:
1. one at
SocketChannelImpl(SelectorProvider selectorProvider)
with
networkSystem.createSocket(fd, true)
2. second one at
SocketChannelImpl.socket()
Then during the closing of channel it closes only socket created by socket() call, but not the socket created via networkSystem.
> [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
> Assignee: Tim Ellison
> 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.
[jira] Commented: (HARMONY-4990) [classlib][nio] file descriptors
leak while work with connections
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536649 ]
Tim Ellison commented on HARMONY-4990:
--------------------------------------
Thanks Sergey, I'm looking into it now.
> [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
> Assignee: Tim Ellison
> 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.
[jira] Commented: (HARMONY-4990) [classlib][nio] file descriptors
leak while work with connections
Posted by "Sergey Dmitriev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536823 ]
Sergey Dmitriev commented on HARMONY-4990:
------------------------------------------
Thanks! :)
> [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
> Assignee: Tim Ellison
> 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.
[jira] Commented: (HARMONY-4990) [classlib][nio] file descriptors
leak while work with connections
Posted by "Sergey Dmitriev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536779 ]
Sergey Dmitriev commented on HARMONY-4990:
------------------------------------------
Aleksey, Tim thanks for your efforts!
Tim, is it possible to provide the patch file here? I just use a pretty previous version and have a dozen of local patches in it so it will be not very easy to jump to the new workspace.
> [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
> Assignee: Tim Ellison
> 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.
[jira] Assigned: (HARMONY-4990) [classlib][nio] file descriptors
leak while work with connections
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Ellison reassigned HARMONY-4990:
------------------------------------
Assignee: Tim Ellison
> [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
> Assignee: Tim Ellison
> 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.
[jira] Resolved: (HARMONY-4990) [classlib][nio] file descriptors
leak while work with connections
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Ellison resolved HARMONY-4990.
----------------------------------
Resolution: Fixed
Thanks Sergey.
Fix applied to NIO module at repo revision r587087.
Please check this fully resolves the issue.
> [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
> Assignee: Tim Ellison
> 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.
[jira] Commented: (HARMONY-4990) [classlib][nio] file descriptors
leak while work with connections
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ 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.