server select : 100% cpu

[GoogleCodeExporter]

Problem similar to issue #17 but "selector.select(timeout);" does not return 0, 
so the sleep is not reached.

The thread loops until the next select in :
for(Iterator<SelectionKey> iter = keys.iterator(); iter.hasNext();) {
[...]
if (udp != null && fromConnection.udpRemoteAddress == null) continue;

Running KryoNet 2.09 
java version "1.7.0_04"
GNU/Linux x86_64 Ubuntu 9.04

Original issue reported on code.google.com by Piladong@gmail.com on 25 May 2012 at 2:48

[GoogleCodeExporter]

Can you provide simple example code that reproduces the problem?

Original comment by nathan.s...@gmail.com on 25 May 2012 at 6:59

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I had the issue after a few tries with these server/client  : 

--------------------
import java.io.IOException;
import com.esotericsoftware.kryonet.Server;
public class Main
{
    private static final int TCP_PORT = 4321;
    private static final int UDP_PORT = 54321;  

    public static void main(String[]a)
    {
        try
        {
            Server server = new Server();
            server.bind(TCP_PORT, UDP_PORT);
            server.start();
        }
        catch (IOException e)
        {
            e.printStackTrace();
        }
    }
}
--------------------

and a simple client : 

--------------------
import com.esotericsoftware.kryonet.Client;

public class Main
{
    private static final int TCP_PORT = 4321;
    private static final int UDP_PORT = 54321;
    private static final int TIMEOUT = 5000;
    private static final String SERVER_IP = "xx.xx.xx.xx";  

    public static void main(String[]a)
    {
        try
        {
            Client client = new Client();
            client.start();
            client.connect(TIMEOUT, SERVER_IP, TCP_PORT, UDP_PORT);
            for(int i = 0;i<100;++i)
            {
                client.connect(TIMEOUT, SERVER_IP, TCP_PORT, UDP_PORT);
                System.out.println("send : "+client.sendTCP("hello #"+i));
                client.close();
                Thread.sleep(10);
            }
            System.exit(0);
        }
        catch (Exception e)
        {
            e.printStackTrace();
        }
    }
}
--------------------

I don't understand what triggers the problem, the server's select returns 
something != 0 (with no timeout/thread sleep) without any client.
I add a new example if i find something better for reproducing the problem.

Original comment by Piladong@gmail.com on 25 May 2012 at 11:29

[GoogleCodeExporter]

I have the simple server posted above running on my server at 100% cpu with 
remote debug, if you want to have a look.

Original comment by Piladong@gmail.com on 25 May 2012 at 12:18

[GoogleCodeExporter]

Ok i found an example that always triggers the problem.
Same server as above and this client (without starting the client thread, so 
the registration times out) : 

--------------------
import com.esotericsoftware.kryonet.Client;

public class Main
{
    private static final int TCP_PORT = 4321;
    private static final int UDP_PORT = 54321;
    private static final int TIMEOUT = 5000;
    private static final String SERVER_IP = "xx.xx.xx.xx";  

    public static void main(String[]a)
    {
        try
        {
            Client client = new Client();
            client.connect(TIMEOUT, SERVER_IP, TCP_PORT, UDP_PORT);
            System.exit(0);
        }
        catch (Exception e)
        {
            e.printStackTrace();
        }
    }
}
--------------------

Actually the problem occurs when the client registration fails.

Original comment by Piladong@gmail.com on 25 May 2012 at 1:00

[GoogleCodeExporter]

This issue was closed by revision r111.

Original comment by nathan.s...@gmail.com on 26 May 2012 at 7:51

• Changed state: Fixed

[GoogleCodeExporter]

Thanks a lot for the test, I see the same behavior. Reading from the channel 
when it is being selected repeated shows the channel is closed. I think the 
channel should be closed if the TCP channel is selected and UDP has not been 
registered. This resolves the problem.

Original comment by nathan.s...@gmail.com on 26 May 2012 at 7:53