harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Shipilev (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-4990) [classlib][nio] file descriptors leak while work with connections
Date Mon, 22 Oct 2007 12:11:50 GMT

    [ 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.


Mime
View raw message