Tomcat6 on Linux uses 100% CPU whenever ServerSocket is idle

Question

Greetings

I am running my webapp on Tomcat6 on Java6 on Ubuntu8.04. The main servlet of this app opens a ServerSocket, with the following simple code:

ServerSocket serverSocket = new ServerSocket(6767);

Socket xmlSocket = serverSocket.accept();        

Of course this runs in a separate thread and with the necessary try-catch blocks.

When I start Tomcat, it immediately goes to 100% CPU load and stays there until a client connects on port 6767. For as long as the client is connected, load goes down to 0%. As soon as the client disconnects, load goes back up to 100%.

Can anybody tell me what this is about?

Thanks!

SOLUTION:

Both the answers below were very helpful. The problem did NOT actually have to do with the ServerSocket, but with a sleepless while loop in a completely different thread of the app, but also dependent on whether a client was connected or not.

I was able to identify the active threads with the JDK command "jstack" and then it was an easy thing to find the one with the runaway loop.

Thanks for the help! :)

Answer 1

As soon as the client disconnects, load goes back up to 100%.

This is usually the case in a "while loop" without sleep() in it.
See this thread for illustration.

Example:

try
{
  while (m_flagRunUserThreadManager)
  {
    try
    {
      m_listenSocket.setSoTimeout(10000);
      Socket clientSocket = m_listenSocket.accept();
      //create a thread for client
      MyClientHandler clientHandler = new ClientHandler(clientSocket);
      clientHandler.setPriority(Thread.MIN_PRIORITY);
      clientHandler.start(); 

    }
    catch(SocketTimeoutException excp)
    {
      String strError = "No requests for 10 Sec.";
      //display this message    
    }
  }
}
catch(IOException excp)
{
    // display the exception
}

This is because your while loop has a path through it with no sleep, specifically when your try fails.
You need to have a sleep somewhere, so other threads/processes get a chance. Either that or don't keep trying on a client that has alreay failed.

Answer 2

Perhaps the easiest way to work out what's going on is to wait for it to run at 100%, and generate a thread-dump via Ctrl-Break (or use SendSignal or similar). You'll get the set of threads together with their state, and it should be obvious as to which one is running, and where it is in the code.