harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Dmitriev (JIRA)" <j...@apache.org>
Subject [jira] Created: (HARMONY-4990) [classlib][nio] file descriptors leak while work with connections
Date Mon, 22 Oct 2007 09:46:50 GMT
[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.


Mime
View raw message