NIO client giving exception : java.net.ConnectException: Connection refused: no further information

后端 未结 3 741
生来不讨喜
生来不讨喜 2020-12-18 04:27

I modified the sample code available here for Client and Server My client :

public class Client {

public static void main(String[] args) {

    int n=10000;         


        
相关标签:
3条回答
  • 2020-12-18 04:41

    Try doing Telnet using command -

    telnet [host IP] [port] 
    

    Issue may be with firewall blocking port.

    0 讨论(0)
  • 2020-12-18 04:50

    ConnectException: connection refused means nothing was listening at the IP:port you tried to connect to, or on some platforms that the server's listen-backlog queue filled up. If it is thrown and you catch it correctly, you will certainly catch it. You would have to expand on what actually happens and what your actual catch code looks like for further assistance.

    However you have many other problems:

    private void connect(SelectionKey key) throws IOException {
        SocketChannel channel = (SocketChannel) key.channel();
        try
        {
            if(!channel.finishConnect())
                System.out.println("* Here *");
    

    At this point, if finishConnect() returned false, you should return. You should not fall through and re-register the channel for OP_WRITE. The connection is still pending. Printing "* Here *" is also pretty futile. Try printing something meaningful.

        }
        catch(ConnectException e)
        {
            System.out.println("BP 1");
            e.printStackTrace();
    
            //channel.close();
    

    You should certainly close the channel at this point. It is of no further use to man or beast.

            //key.cancel();
    

    Closing the channel cancels the key. Remove wherever encountered.

            //return;
    

    As above, you should certainly return at this point.

        }
        /*if (channel.isConnectionPending()){
            while(!channel.ffinishConnect()){
                System.out.println("not connected");
            }
        }*/
    

    Get rid of this crud. It is never appropriate to spin-loop in non-blocking mode. Don't even leave it lying around as comments: some idiot may come along later and play with putting it back.

        channel.configureBlocking(false);
    

    The channel is already in non-blocking mode. Otherwise you wouldn't be here. Remove.

        channel.register(selector, SelectionKey.OP_WRITE);
    

    Another way to do that is key.interestOps(SelectionKey.OP_WRITE);

    Sleeping in networking code is literally a waste of time. It doesn't solve anything.

    You are assuming that write() succeeded completely, and you're ignoring the count it returns.

    You're using a fairly poor quality reference:

    • Same remarks about write() apply as above.
    • flip() is not 'like a reset'.
    • Cancelling a key closes the channel.
    • You don't have to clear a brand-new ByteBuffer, but in any case allocating a ByteBuffer per read is poor practice.
    • ServerSocketChannel.accept() can return null.
    • The code that displays a String after reading is incorrect.
    • There is no need to use a Map when keys have attachments.
    • There's no need to keep testing Thread.interrupted() when NIO is interruptible anyway.
    • There's no need to close everything just becaues of one IOException on one channel.

    Try to find something better.

    0 讨论(0)
  • 2020-12-18 05:07

    I believe the ConnectException you are getting with 500 threads is not coming from SocketTest.connect(). It could be coming from any of the other IO methods.

    For a quick fix (and to convince yourself), you can explicitly catch ConnectException in your main try-catch block like this:

    try {
        // connect, write, and read ...
    } catch (ConnectException ce) {  // <-- catch the more specific Exception first
        System.out.println("You caught a ConnectException.");
    } catch (IOException e1) {       // <-- you originally only caught this
        // TODO Auto-generated catch block
        e1.printStackTrace();
    } finally {
    

    As to why this is happening, I can tell you that I am currently ramping up to hundreds of threads for testing a SOAP service. I also get dropped connections all over the place, so maybe this is to be expected with such a large number of concurrent threads.

    0 讨论(0)
提交回复
热议问题