CODEWITHSUNDEEP
javalinuxsocketstcpnio
Supriya Kulkarni
Supriya Kulkarni

Reputation: 11

Java NIO client causes file descriptor leakage only when remote TCP server is down

The below program acts as TCP client and uses NIO to open socket to a remote server, as below

private Selector itsSelector;
private SocketChannel itsChannel;

public boolean getConnection(Selector selector, String host, int port)
{
    try
    {
        itsSelector = selector;
        itsChannel = SocketChannel.open();
        itsChannel.configureBlocking(false);
        itsChannel.register(itsSelector, SelectionKey.OP_CONNECT);
        itsChannel.connect(new InetSocketAddress(host, port));
        if (itsChannel.isConnectionPending())
        {
            while (!itsChannel.finishConnect())
            {
                // waiting until connection is finished
            }
        }
        itsChannel.register(itsSelector, SelectionKey.OP_WRITE);
        return (itsChannel != null);
    }
    catch (IOException ex)
    {
        close();
        if(ex instanceof ConnectException)
        {
            LOGGER.log(Level.WARNING, "The remoteserver cannot be reached");
        }
    }
}

public void close()
{
    try
    {
        if (itsChannel != null)
        {
            itsChannel.close();
            itsChannel.socket().close();
            itsSelector.selectNow();
        }
}   
    catch (IOException e)
    {
        LOGGER.log(Level.WARNING, "Connection cannot be closed");
    }
}

This program runs on Red Hat Enterprise Linux Server release 6.2 (Santiago) When number of concurrent sockets are in establishment phase, file descriptor limit reaches a max value and I see below exception while trying to establish more socket connections.

java.net.SocketException: Too many open files
               at java.net.PlainSocketImpl.socketAccept(Native Method)
               at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)

This happens only when the remote Node is down, and while it is up, all is fine. When the remote TCP server is down, below exception is thrown as is handled as IOException in the above code

java.net.ConnectException: Connection refused: no further information
    at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
    at sun.nio.ch.SocketChannelImpl.finishConnect(Unknown Source)

Is there any way to forcefully close the underlying file descriptor in this case. Thanks in advance for all the help.

Upvotes: 1

Views: 1113

Answers (1)

user207421
user207421

Reputation: 310850

private Selector itsSelector;

I cannot see the point of this declaration. You can always get the selector the channel is registered with, if you need it, which you never do. Possibly you are leaking Selectors?

itsChannel.configureBlocking(false);
itsChannel.register(itsSelector, SelectionKey.OP_CONNECT);

Here you are registering for OP_CONNECT but never making the slightest use of the facility.

itsChannel.connect(new InetSocketAddress(host, port));

Here you are starting a pending connection.

if (itsChannel.isConnectionPending())

It is. You just started it. The test is pointless.

{
    while (!itsChannel.finishConnect())
    {
        // waiting until connection is finished
    }
}

This is just a complete waste of time and space. If you don't want to use the selector to detect when OP_CONNECT fires, you should call connect() before setting the channel to non-blocking, and get rid of this pointless test and loop.

    itsChannel.register(itsSelector, SelectionKey.OP_WRITE);
    return (itsChannel != null);

itsChannel cannot possibly be null at this point. The test is pointless. You would be better off allowing the IOExceptions that can arise to propagate out of this method, so that the caller can get some idea of the failure mode. That also places the onus on the caller to close on any exception, not just the ones you're catching here.

catch (IOException ex)
{
    close();
    if(ex instanceof ConnectException)
    {
        LOGGER.log(Level.WARNING, "The remoteserver cannot be reached");
    }
}

See above. Remove all this. If you want to distinguish ConnectException from the other IOExceptions, catch it, separately. And you are forgetting to log anything that isn't a ConnectException.

public void close()
{
    try
    {
        if (itsChannel != null)
        {
            itsChannel.close();
            itsChannel.socket().close();
            itsSelector.selectNow();

The second close() call is pointless, as the channel is already closed. 

catch (IOException e)
{
    LOGGER.log(Level.WARNING, "Connection cannot be closed");
}

I'm glad to see you finally logged an IOException, but you're not likely to get any here.

Don't write code like this.

Upvotes: 4

Related Questions